Batch and Stream Processing: Choosing the Right Delay

Some data can wait until tonight. Some decisions lose value after seconds.

A nightly revenue report and fraud scoring both process transactions, but their latency requirements are fundamentally different.

Batch processing handles bounded collections; stream processing continuously handles events as they arrive.

Lower delay adds ordering, state, replay, and operational complexity.

A concrete example: revenue and fraud

Revenue reporting:

• reads yesterday's completed transactions,
• aggregates by region,
• publishes at 06:00.

Fraud scoring:

• evaluates each payment before authorization,
• combines recent account activity,
• responds in milliseconds.

The business deadline determines the processing model.

Bounded data

A batch has a known boundary:

• file,
• date partition,
• table snapshot,
• or query result.

The job can know when it has processed all input and then publish one output.

Batch scheduling

Batches run:

• hourly,
• nightly,
• on file arrival,
• or on demand.

Schedules should reflect downstream need and source readiness, not tradition.

Batch advantages

Batch offers:

• simple completeness,
• efficient bulk operations,
• easy recomputation,
• and lower always-on cost.

Many business questions do not benefit from second-level freshness.

Batch disadvantages

Delay can mean:

• late fraud detection,
• stale inventory,
• delayed alert,
• or slow feedback.

Large batches create recovery pressure if one run fails near a deadline.

Streams

A stream is an ongoing sequence of events:

• clicks,
• payments,
• sensor readings,
• database changes,
• or log entries.

The processor handles events continuously and updates outputs incrementally.

Stream advantages

Streams support:

• low-latency decisions,
• live dashboards,
• event-driven workflows,
• and continuous derived state.

They spread processing over time rather than one nightly peak.

Stream complexity

Streams must define:

• event time,
• processing time,
• ordering,
• duplicate delivery,
• state,
• windows,
• late data,
• and replay.

The result may change as delayed events arrive.

Stateless processing

Stateless operations transform each event independently:

• parse,
• filter,
• enrich from fixed configuration,
• route.

They scale easily by partition because no accumulated history is needed.

Stateful processing

Stateful operations remember:

• count per user,
• rolling total,
• session,
• join buffer,
• or fraud features.

State needs partitioning, checkpointing, recovery, expiration, and consistent updates.

Windows

Infinite streams are grouped into windows:

• tumbling five-minute windows,
• sliding one-hour windows,
• session windows separated by inactivity.

Window definition becomes part of metric meaning.

Event time

Event time is when the real activity happened.

Processing time is when the system saw it. Network and offline devices make them differ.

Watermarks estimate when a window is complete enough to publish.

Ordering

Global ordering is expensive.

Streams usually preserve order within a partition key. Events for one account can remain ordered while different accounts process in parallel.

Choose keys according to state and business sequence.

Delivery semantics

Processing may be:

• at most once,
• at least once,
• or exactly once within a defined system boundary.

Business effects still need idempotency when external systems are involved.

Checkpoints

Stream processors periodically save:

• source offsets,
• operator state,
• and output coordination.

After failure, they restore and replay from a checkpoint.

Checkpoint frequency balances recovery work and overhead.

Replay

Retained event logs support:

• recovery,
• new consumers,
• bug correction,
• and backfill.

Replay can repeat side effects, so distinguish state rebuilding from live notifications or payments.

Unified business logic

When batch and stream paths calculate the same metric independently, their definitions can drift.

Share transformation libraries or declarative models where practical, and reconcile real-time results against periodic complete batches. Differences should become visible quality signals rather than two dashboards that silently disagree.

Stream-table duality

A table can be viewed as the latest result of an event stream, while a stream can be viewed as changes to a table.

This perspective helps design change-data capture, materialized views, and replay. It does not remove the need to define keys, deletes, ordering, and retention.

Backpressure

If processing falls behind, consumer lag grows.

Systems can:

• slow ingestion,
• add capacity,
• shed optional work,
• or buffer within retention.

Monitor oldest-event age, not only record count.

Exactly-once scope

A stream engine may coordinate source offsets and internal state exactly once within its checkpoint protocol.

Calling an external payment or email service remains outside that transaction unless the endpoint supports idempotency. State the guarantee boundary precisely so transport terminology is not mistaken for one business effect.

Lambda and kappa ideas

Some architectures use:

• batch for complete correctness,
• streaming for fast approximate updates,
• then reconcile.

This duplicates logic. A stream-first design may replay the log for historical recomputation.

Choose simplicity and correctness for the actual platform.

Micro-batching

Micro-batch systems process small batches every few seconds.

They offer near-streaming latency with batch execution semantics.

The distinction between batch and stream is therefore a continuum of delay and state management.

Cost

Always-on stream infrastructure costs continuously.

Batch can use temporary elastic compute. Streaming may avoid large peaks and support valuable immediate action.

Compare business value of freshness with operational cost.

Choosing

Ask:

1. How quickly does the output lose value?
2. Is data bounded?
3. Can results change after late events?
4. What state is needed?
5. Must history be replayed?
6. Can the team operate continuous processing?

Knowledge check

1. What makes a dataset bounded?
2. Why does stream processing need windows?
3. Which additional responsibilities come with stateful processing?
4. Why can replay repeat harmful side effects?
5. How does micro-batching sit between classic batch and streaming?

The one idea to remember

Batch systems process complete bounded collections efficiently; stream systems update continuously for lower delay. Choose the latency that creates business value, then accept the corresponding complexity in time, ordering, state, replay, delivery, recovery, and cost.