Stateful Stream Processing
Stream computations that must remember information across events — aggregations, joins, deduplication, sessionisation — and the durability machinery that makes them recoverable.
Stateless transformations are easy to operate: any instance can process any event and a failure costs one retry. State changes everything, because the computation now depends on history that must survive a crash, a rebalance and a redeploy.
The machinery that provides this is consistent: state is held locally for speed, usually in an embedded key-value store, backed by a changelog written to durable storage, with periodic checkpoints capturing state and input offsets together so recovery restores a mutually consistent pair.
The operational consequences are what architects need to price in. Recovery time is dominated by restoring state, which for large state is minutes rather than seconds, and this is your real time to recover — not the time to restart a process. Rescaling redistributes key ranges, so state must move between instances, which is a slow and delicate operation on large state. And state size grows without bound unless retention or time-to-live is set deliberately, which is how streaming jobs run happily for four months and then fail on disk.
The design lever that matters most: bound the state. Windowed aggregations expire naturally; unbounded per-key state, such as deduplication across all history, does not, and needs an explicit retention decision tied to what correctness actually requires.