Lambda and Kappa are the two classic shapes for systems that need both fresh and correct analytics. Lambda runs a batch path and a streaming path in parallel and merges them when you query. Kappa keeps only the streaming path and recomputes history by replaying a retained log. This page draws both side by side, then shows how Kappa reprocesses.
These are architecture diagrams, not UML. UML covers software structure and behaviour; boxes-and-arrows data architecture views are one of the other standard notations used alongside it.
1. The Diagram
Lambda, batch path. Every event lands in an immutable master dataset. A batch job recomputes complete views from scratch every few hours. Correct, but stale.
Lambda, speed path (yellow). The same events go through a stream processor that maintains approximate views covering only the hours the batch has not reached yet.
Lambda, serving. A query combines both: batch view up to the last batch run plus the real-time delta since then. When the next batch lands, the speed layer's old data is discarded.
Kappa, single path. Events go into a Kafka log retained long enough (or forever, with tiered storage). One stream job writes the serving store.
Kappa, reprocessing (dashed). To fix a bug or change logic, start the job again from offset 0. The log is the master dataset.
2. How to Read It
Colour by processing mode: blue batch, yellow streaming, green what users query. The visual test is simple: count the parallel paths. Two paths means two codebases implementing the same logic, which is Lambda's main cost.
3. Variant: Kappa Reprocessing
Kappa replaces "rerun the batch" with "run a second copy of the stream job". Version 2 reads from the start of the log into a new table while version 1 keeps serving. When v2 reaches the head, the alias or view is repointed and v1 is stopped. This needs enough log retention, enough spare compute to read history quickly, and a sink that can be swapped atomically.
4. Pros, Cons, and When to Use
Pros
Side-by-side drawing makes the trade-off obvious: duplicate logic vs replay cost.
Shows where freshness and correctness come from in each design.
Simple boxes; any stakeholder can follow it.
Highlights operational components (log retention, serving merge) that are easy to forget.
Good anchor for choosing between Spark batch, Flink, or a lakehouse with streaming tables.
Cons
Idealised: real systems are hybrids (lakehouse streaming tables blur the line).
Hides scale details such as partitions, state size and checkpointing.
No timing information: how stale is batch, how fast is replay?
Product names in boxes date quickly.
Can suggest Lambda is obsolete when it still fits regulated batch reporting.
When to use
Architecture decision records for real-time analytics.
Explaining why a team keeps two codebases.
Planning a migration from Lambda to Kappa or a lakehouse.
When not to use
Detailed stream job design (use a streaming topology).