Checkpoint Interval
How often a stateful processor persists its state and offsets, which trades steady-state overhead against how much work is redone after a failure.
A stateful operator holds accumulated state — window contents, join buffers, running aggregates. Periodically it writes that state durably alongside the input offsets it reflects, so recovery can resume from a consistent point.
The interval sets a direct trade. Frequent checkpoints mean little reprocessing after a failure and constant background I/O that competes with the actual work. Infrequent checkpoints mean cheap steady state and a long catch-up after a restart, during which the pipeline is behind and lag is growing faster than it can be consumed.
The number that is usually missed is restore time, which depends on state size rather than on the interval. A job with two hundred gigabytes of keyed state may take many minutes to reload before it processes a single new record, and during that time lag accumulates. Recovery is therefore not the checkpoint interval; it is restore time plus the time to work through the backlog, and the second term can dominate.
Incremental checkpointing, which persists only changed state, is what keeps this tractable as state grows — and choosing a state backend that supports it is a decision made at the start and expensive to revisit.