Lambda vs Kappa (batch + stream)
Streaming is fast but hard; batch is simple but slow; you need both speed and correctness.
At a glance
| What | Streaming is fast but hard; batch is simple but slow; you need both speed and correctness. |
|---|---|
| When | Lambda when reprocessing is cheap and latency needs are moderate; Kappa when streams are replayable and ops budget is limited |
| Where | Streaming |
Problem
Streaming is fast but hard; batch is simple but slow; you need both speed and correctness.
Solution
Lambda: run a batch layer (authoritative, reprocessable) and a speed layer (approximate, low-latency), merge at query time. Two code paths, two bugs. Kappa: one streaming path; reprocessing = replay the log. Simpler, but the log must retain enough history and the stream must be replay-safe. Modern default: a single lakehouse path with replayable streams (a pragmatic kappa), keeping raw immutable so history is always reprocessable.
When not to use
- Neither, if a nightly batch genuinely meets the SLA — keep it simple
Security scan
Last sweep 2026-10-24: 0 finding(s), 0 marked as examples.
Context
An analytics need with both a latency requirement and a need to reprocess history.
Forces
- Freshness needs
- Reprocessing needs
- Operational complexity budget
- Consistency between batch and stream logic
Tradeoffs
- lambda pro: batch correctness; con: two implementations to keep consistent
- kappa pro: one code path; con: requires long log retention + replay safety
Diagram
Lambda: source ─┬─ batch (authoritative) ─┐
└─ speed (approx) ─┴─▶ serve
Kappa: source ─▶ stream ─▶ table ─▶ serve (reprocess = replay)
Registry stats
| Verification | community · Sep 17, 2026 |
|---|---|
| Completeness | 75 |
| Trust multiplier | ×1.25 |
| Composite | 34.75 · adequate |
| Freshness | 37 days since last source check |
| Difficulty | advanced |
| Version | 1.0.0 |
| License | CC-BY-4.0 |
| Security flags | none |
Did this solve your problem?
Lambda vs Kappa (batch + stream)