Processing modes

A processing mode defines how a scenario handles records — how they are received, processed, and produced.

Processing mode is one of the three dimensions described in How Nussknacker runs, alongside the engine and deployment target. It describes the interaction pattern of a scenario; the engine determines the runtime capabilities available to execute it.

Nussknacker currently supports two processing modes:

• Streaming — processes records continuously as they arrive.
• Request-Response — processes one record on demand and returns one response.

Batch processing is planned and will extend the set of available processing modes in the future.

note

In this documentation, record is a neutral term used across all processing modes.

In streaming contexts, you may also see the term event — a record with an event timestamp used for time-based processing.

Streaming mode

In streaming mode, a scenario runs continuously and processes a flow of incoming events as they arrive. It can produce results whenever its logic requires — for example immediately for each event, after several related events have been observed, or when a time window closes.

Streaming scenarios are data-driven: new events entering the scenario trigger processing without an external caller requesting an individual decision.

Stateful and stateless streaming

Streaming mode can use either the Lite or Flink engine.

• Lite executes streaming scenarios without keeping state between records.
• Flink supports stateful stream processing. A scenario can retain information across events and use event time to reason about activity over time.

With the Flink engine, state can hold, for example, a customer's running totals, the last seen status of an order, or activity observed within a time window. This enables scenarios to:

• aggregate over time, such as counts, sums, and averages,
• correlate events into sessions or patterns,
• de-duplicate records,
• retain previous values and other information needed when later events arrive,
• process time windows and handle late or out-of-order events.

The processing mode therefore tells you that a scenario is continuous and event-driven; the engine determines whether stateful and time-based processing capabilities are available.

When to use streaming

Streaming mode is suitable when processing should happen continuously as new data arrives, for example:

• ongoing monitoring and alerting,
• fraud or anomaly detection,
• real-time customer or session decisions,
• continuously updated counters and KPIs,
• event correlation and pattern detection.

Read this document for more details about the streaming processing mode.

Request-response mode

In request-response mode, a scenario acts as an on-demand decision service. A calling system sends input data — the request — and receives the decision or answer in the same call.

Each invocation processes one request and produces one response. Scenario state is not retained between calls; when decisions require historical or shared information, the scenario can obtain it from external systems through enrichers or other components.

Request-response mode uses the Lite engine.

When to use request-response

Request-response mode is suitable when another system needs an immediate answer, for example:

• eligibility, pricing, or risk decisions,
• API-based decision services,
• "lookup + rules + answer" flows for web or mobile applications,
• decisions that use information stored in external systems rather than state maintained inside the scenario.

Streaming and request-response compared

	Streaming	Request-response
Execution	Runs continuously	Runs on demand
Triggered by	Incoming records/events	An external request
Output	Results produced as processing progresses	One response per request
Engines	Lite or Flink	Lite
State between records/calls	Depends on the engine: stateless with Lite, stateful with Flink	Stateless; use external systems when history is needed
Time-based processing	Available with the Flink engine	Not applicable to the processing model

Read this document for more details about the request-response processing mode.