Micro-batch or True Streaming?
Both engines read the same log and write the same sink, and the difference is what happens between. A micro-batch engine waits for a trigger interval and takes every event that arrived during it. It plans and runs that set as a small batch job, then commits the source offsets before the next interval starts. A record-at-a-time engine pushes each event through the operator graph the moment it arrives, updating state per event and emitting results as soon as a window closes. The first reuses the batch planner and pays a latency floor equal to the trigger. The second removes the floor and pays with a second runtime to operate.
Where the latency comes from
Take a 10 second trigger. The timeline below follows 2 events through 1 cycle. An event that arrives at the start of the interval waits almost the full 10 seconds for the trigger, then waits for the batch to run. An event arriving at the end waits only for the run. The consumer sees results in steps, every 10 seconds plus the run time, with p99 near the full trigger plus the slowest run.
| Clock | Event arriving at 10:00:01 | Event arriving at 10:00:09 |
|---|---|---|
| 10:00:00 | interval opens | interval opens |
| 10:00:01 | arrives, waits | |
| 10:00:09 | arrives, waits | |
| 10:00:10 | trigger fires, 20,000 events planned as 1 batch | same batch |
| 10:00:13 | batch commits, result visible | result visible |
| End to end | 12 s | 4 s |
Shrinking the trigger lowers the floor but raises the overhead. Each cycle pays a fixed cost for planning and committing offsets, around 1 second on a typical cluster, so a 2 second trigger spends half its time on overhead and a 100 ms trigger spends almost all of it. Below about 1 second the micro-batch model stops paying, and that is the line the record-at-a-time engine exists to cross.
- Micro-batch
- Latency floor: the trigger plus the run, 1 s to minutes
- Throughput: high per node, the batch planner optimizes each cycle
- State: snapshotted once per cycle with the offsets
- Code: the same functions and cluster as the batch jobs
- Failure unit: 1 cycle reruns whole
- Skills: the batch team already has them
- Record-at-a-time
- Latency floor: the processing path, 10 to 100 ms
- Throughput: high, with per-event overhead on hot keys
- State: kept per operator, snapshotted on an interval
- Code: a separate API, often a separate cluster
- Failure unit: the job restores from its last checkpoint
- Skills: a second runtime to learn and page on
Match to the SLA first, then to the team
The decision has 2 steps in order. First, the SLA against the latency floor. A trigger needs to be a fraction of the SLA so that p99 lands under it: a 5 minute SLA tolerates a 30 second trigger with room to spare, a 2 second SLA tolerates no trigger at all. Second, when both engines meet the SLA, the team decides. A team that runs the batch engine already gets the micro-batch stream on the same cluster, with the same functions, the same deploy pipeline and the same on-call rotation. Choosing the record-at-a-time engine for that team adds a runtime they must learn, with its own state backend and checkpoint store, for a latency the SLA never asked for.
| Workload | SLA | Engine | Why |
|---|---|---|---|
| Card fraud score | 300 ms | record-at-a-time | no trigger fits under the SLA |
| Rider ETA | 2 s | record-at-a-time | a 1 s trigger plus the run misses p99 |
| Stockout alert | 5 min | micro-batch, 30 s trigger | p99 around 40 s, on the existing cluster |
| Ad click attribution | 1 hour | micro-batch, 5 min trigger | shares code with the hourly rebuild |
| Ops wall screen | 1 min | micro-batch, 10 s trigger | nobody acts faster than the glance |
The ETA row deserves the extra sentence an interviewer waits for. A 1 second trigger plus a 1 second run gives a p50 near 1.5 seconds and a p99 near 2.5 seconds, over the 2 second SLA, so micro-batch fails on the tail while passing on the median. Tail latency is where the trigger model loses, and saying so shows the reasoning behind the choice.
Some micro-batch engines offer a continuous mode with sub-second latency and weaker guarantees. In an interview, treat it as a footnote: the decision still comes down to the SLA and to who operates the job.
About this lesson
This section is part of the Batch or Stream?: Intermediate lesson on DataDriven, the home of data engineering. Lessons cover SQL, Python, Spark, data modeling and pipeline architecture, and each section pairs its explanation with worked examples and practice you run as you go.