Life of an Event-Time Window — Watermarks, Stragglers, Corrections Diagram

Why Windows Use Event Time

A window groups events by the timestamp embedded in each event, not by the clock of the machine doing the processing
Event-time windowing is deterministic: running the same job again over the same input yields the same window contents and the same result
Processing-time windowing breaks under lag — a redeploy and backlog make a steady request rate look like a spike (Figure 12-8)

When Is a Window Finished?

With event time you can never be sure all events for a window have arrived; some may be buffered on another machine after a network interruption
A timeout works approximately: declare the window ready after a while with no new events for it
A watermark message — "from now on, no more messages with a timestamp earlier than t" — lets consumers trigger windows, but each producer's threshold must be tracked separately

Two Ways to Handle Stragglers

Ignore them: stragglers are a small percentage in normal circumstances — track the drop count as a metric and alert if a significant amount of data is dropped
Or publish a correction: an updated value for the window with stragglers included, retracting the previous output first
A restart replays the input log in event-timestamp order, so the rebuilt window matches what the job had before the crash