Comparison
Allowed latenessvsWindow trigger
Allowed lateness
the window emitted a result at 15:00 and keeps updating it for another two hours before it finally throws the state away.
How long after a window closes the job will still accept and re-emit for records belonging to it. It buys correctness with memory and with downstream churn — every update is a rewrite somebody has to handle — and it is bounded because state cannot be kept forever. Setting it is a business conversation dressed as a config value: how wrong may this number be for how long, and can the consumer cope with it changing.
Full entry →Window trigger
the dashboard shows a partial count that keeps rising, because the window emits early every ten seconds before it finally closes.
The rule that decides when a window produces output — on watermark, early on a timer or a count, or late when more data arrives. Separating it from the window definition is what lets you have both a fast approximate answer and a correct final one from the same job. Whoever consumes the output has to know which they are looking at, since an early fire and a final fire are indistinguishable unless you label them.
Full entry →