Comparison
Out-of-order eventsvsWatermark
Out-of-order events
the update arrived before the insert, and your naive consumer wrote a row it then couldn't find a parent for.
Records reaching your job in a different order from the one they happened in, which is the normal condition of anything with more than one partition or more than one producer. Ordering usually holds within a partition key and never across keys, so the design question is whether your key is the same as your ordering requirement. When it is not, correctness has to come from event-time logic or version numbers rather than from arrival sequence.
Full entry →Watermark
the job announces that it believes nothing older than 14:30 is still coming, and closes every window that ended before then.
The stream's assertion about how far event time has advanced — a claim that records older than this are no longer expected. It is what lets an unbounded stream ever produce a finished answer, because a window cannot close until something declares the input for it complete. It is a heuristic, not a fact: set it aggressively and you drop real data, set it conservatively and every result waits, which is the central tuning decision in any streaming job.
Full entry →