Replay Pipeline
A single processing path that produces both live and historical results by re-running the same code over retained input, replacing the two-path Lambda arrangement.
Lambda architecture runs a batch path for correctness and a speed path for freshness, then reconciles. The cost is two implementations of the same business logic in different technologies, which drift, and a reconciliation step that becomes the source of most incidents.
The Kappa alternative keeps one path. The input log is retained long enough to replay, so recomputing history means starting a second instance of the same job from an earlier offset, letting it catch up, and switching consumers to its output. There is only one implementation, so there is nothing to reconcile.
What it requires is often the reason it is not chosen: retention long enough to cover the replay you might need, throughput headroom to run a catch-up job alongside live traffic, and downstream sinks that tolerate a rebuilt output.
The honest position is that the choice is not ideological. Where the history is short and the sources are replayable, one path is clearly better. Where the authoritative history lives in a warehouse spanning years, a batch path over that history and a stream for recent data is the pragmatic arrangement — and the discipline is to generate both from one definition rather than to write the logic twice.