DSC3103 ยท Module 6 of 9

Streaming, Event-Time Windows & Watermarks

Process unbounded events with out-of-order arrivals (Lab 9 Part 1)

~56 min to study properly

Batch processing waits for a bounded dataset (like yesterday's file) before computing. Streaming processes an unbounded sequence of events continuously as they arrive from sensors, mobile apps, or market agents.

Checkpoint ยท the examiner asks

Distinguish Event Time from Processing Time. How does a Watermark control when a tumbling window is finalised, and what happens to an event whose timestamp falls behind the watermark?

In one minute

Streaming processes unbounded events continuously. Always bucket by event time, not processing time, because mobile networks deliver events late and out of order. Tumbling windows are [floor(ts/S)ยทS, +S). The watermark W(t) = max_event_ts โˆ’ L says when a window can be finalised; events older than the watermark go to late_events, and a seen_ids store drops duplicate retries.

Traps examiners look for
  • Grouping by processing time so delayed events land in the wrong window.
  • Setting allowed lateness to 0 and losing every slightly late event.
  • Deduplicating after windowing instead of before.
Read

Study notes

01Batch vs stream

Batch processing waits for a bounded dataset โ€” yesterday's file โ€” then processes it all at once. Simple, but results are only as fresh as the last batch.

Streaming processes an unbounded sequence of events continuously as they arrive: market agents reporting prices from their phones, sensors, clicks. Results update within seconds.

Streaming forces three questions batch never asks: Which time do I group by? When is a result final? What do I do with data that arrives late or twice?

02Event time vs processing time

Every event has two timestamps:

  • Event time โ€” when the thing actually happened (the price was observed at 08:00:05).
  • Processing time โ€” when our system received it (the phone had no signal; it arrived at 08:00:19).

If you group by processing time, delayed events land in the wrong window and your "08:00โ€“08:10 average price" quietly includes prices from other periods. Correct analytics groups by event time.

Tumbling windows are fixed, non-overlapping buckets: for 10-second windows, an event at t falls in [โŒŠt/10โŒ‹ยท10, โŒŠt/10โŒ‹ยท10 + 10). An event at 1,238.4 s goes to [1230, 1240).

03Watermarks decide when a window is final

With out-of-order data you can never be sure no more events for a window will arrive. A watermark is the system's assumption about how late events can be:

W(t) = max event time seen so far โˆ’ L, where L is the allowed lateness.

  • Any window whose end โ‰ค W(t) is finalised and emitted โ€” its result won't change.
  • An event with event_ts < W(t) is late: its window is already closed. Route it to a side output (late_events.jsonl) for auditing or correction instead of silently dropping it.

Choosing L is a trade-off: a small L gives fast, final results but more late events; a large L catches stragglers but holds results back longer and keeps more state in memory.

04Duplicates and state

Mobile clients retry when they don't get an acknowledgement, so the same event can arrive twice. Counting both would inflate volumes and skew averages.

Our Lab 9 consumer keeps state: a set of seen_ids. The order of checks matters:

watermark = max_event_ts - allowed_lateness
if event_id in seen_ids:        route("duplicates")      # 1. drop retries first
elif event_ts < watermark:      route("late_events.jsonl") # 2. too late for its window
else:
    windows[(int(event_ts) // 10) * 10].add(event)        # 3. bucket by event time
    seen_ids.add(event_id)

State can't grow forever: once a window is final, the ids of its events can be expired. Accounting identity for a run: emitted = windowed + duplicates + late.

Watch it done

Worked examples

Worked example 1

Classify three events

Max event time seen = 1,250 s, allowed lateness L = 8 s, 10-second windows. Classify events at 1,247 s, 1,238 s and a retry of an already-seen id at 1,249 s.

    Worked example 2

    Picking the allowed lateness

    Measured network delays: 90% of events arrive within 3 s, 99% within 12 s, the worst seen was 40 s. Results must be final within ~15 s. Which L would you choose?

      Vocabulary

      Key terms

      Google Dataflow & Apache Flink popularised Watermarks

      Tyler Akidau's 2015 'Dataflow Model' paper formalised the What / Where / When / How of stream processing โ€” showing that event-time windows + watermarks + triggers unify batch and streaming under a single mathematical model.

      Practise

      Quick check

      0 of 8 correct so far. Wrong answers come with an explanation โ€” and the buddy can unpack them.

      Q1With 10-second tumbling windows starting at t=0, which window `[start, end)` does an event with `event_ts = 1029.8` belong to?

      Q2Max seen event_ts is 1052.0s and allowed lateness L = 5.0s. An out-of-order event arrives with event_ts = 1044.5s. How is it classified?

      Q3An event happened at 08:00:05 and arrived at 08:00:19. Which time should a price window use?

      Q4Which 10-second tumbling window contains event_ts = 1,238.4?

      Q5max_ts = 980 s, L = 15 s. What is the watermark?

      Q6What happens to an event older than the watermark in our consumer?

      Q7Why check seen_ids before the watermark?

      Q8What's the cost of a very large allowed lateness?

      Exam-style

      Written practice

      Short answer5 marks

      Explain the difference between event time and processing time and why it matters for windowed averages.

      Short answer6 marks

      Define a watermark and explain how it decides when a window can be emitted and which events are late.

      Long answer12 marks

      Design the consumer for a real-time market-price stream that receives duplicates (client retries) and late events (poor mobile coverage). Specify the processing order, the windowing, how you choose the allowed lateness, how you bound memory, and the accounting checks you'd run.

      Watch

      Videos

      Fresh picks are chosen by AI every day.
      Hands-on

      Event-Time Tumbling Window & Watermark Simulator

      4 guided tasks: predict, experiment, explain โ€” then challenge yourself. Plus 1 coding exercise you run right in the browser.

      Start the lab