Watermark
A moving assertion that no events older than a given event-time will arrive, which is what allows an event-time window to be closed and emitted.
The problem watermarks solve: with event-time windows, you cannot know when a window is complete. Events arrive out of order — a mobile client was offline, a partition was slow, a retry took a minute — so waiting forever is correct and useless, while emitting immediately is fast and wrong.
A watermark is the system's estimate of progress: "event time has advanced to T; I do not expect anything earlier." When the watermark passes a window's end, the window fires.
The trade is explicit and unavoidable. A conservative watermark waits longer, captures more late data, and adds latency to every result. An aggressive one emits quickly and drops more.
Handling what arrives after the watermark is a design decision with three options: drop it (and count the drops — an unmonitored drop rate is silent data loss), emit an update that corrects the earlier result (which requires every downstream consumer to handle restatement), or hold a late window with an allowed-lateness period before final closure.
Watermarks are usually derived per partition and combined as the minimum across them, which is why a single idle or lagging partition can stall the whole computation — a common and initially baffling production symptom.