Event Time vs Processing Time

Watch delayed IoT events move through event-time windows, watermarks, and late-data policy.

Interactive event-time versus processing-time workbench with animated arrivals, watermark calculation, late-event classification, event-time windows, grace period trade-offs, and mobile learning support.

Stream timing Watermarks Late IoT events

Event time says when the sensor measured. Processing time says when the system found out.

The same reading can be created in one event-time window and arrive much later in processing time. The watermark is the processor's moving line for deciding which event-time results can close.

0.0s Watermark

On time Current decision

[0, 5)s Event-time window

0.0s Arrival lag

Event time The timestamp inside the event payload. Windows should normally use this time because it records when the real-world condition happened.

Processing time The time when the processor receives the event. Network delay, buffering, batching, and outages push this later than event time.

Watermark A monotonic event-time progress estimate. In this teaching model it equals max observed event time minus the watermark delay.

Factory line sensor

A steady local network with one buffered packet shows why event time and arrival order are not the same thing.

On time

watermark 0.0s

A

Event time

Processing time

A at 1.0s Event timestamp

Arrives 1.4s Processing timestamp

Before 0.0s Watermark before event

The first event has no previous high event-time mark, so it opens its event-time window.

1. Measured The device stamps the reading with event time.

2. Delayed Network, buffer, or batch delay separates the two timelines.

3. Received The processor checks the watermark before accepting the event.

4. Windowed The result is assigned by event time, not processing time.

Scenario

Local factory telemetry with a small watermark delay and one buffered packet.

Watermark policy

Changing the policy recalculates every event and window decision in the trace.

Watermark delay

2s

Allowed lateness

3s

Window size

5s

Window status

watermark = max_event_seen - delay window = [floor(event_time / size) * size, start + size)

Processing order

Rows are sorted by processing time. The event-time window can point backward.

How to read the trace

Top timeline: when the event happened at the device. Bottom timeline: when the processor received it. A long horizontal gap means the reading waited in a network, device buffer, or batch.

The watermark line sits on the event-time axis. If an older event arrives to the left of that line, the processor treats it as late and checks whether its event-time window is still inside the allowed lateness period.

Formula reference

Quantity	Teaching formula
arrival lag	processing_time - event_time
watermark	max_event_seen - watermark_delay
window start	floor(event_time / window_size) * window_size
late accepted	event_time < watermark and watermark <= window_end + grace

Production systems can use richer watermark strategies, but the core idea is the same: watermarks bound how long the system waits for older event times.

Design trade-off

• Small watermark delay: faster results, more old events routed to late handling.
• Large watermark delay: more complete results, slower window close times and more retained state.
• Allowed lateness: lets already emitted windows update for a while, but increases correction traffic and state lifetime.

What the animation simplifies

This component uses one ordered stream and one deterministic watermark formula. Real systems may track watermarks per partition, merge watermarks from several sources, emit early results, and send very late events to an audit or replay path instead of dropping them silently.

Stream processing fundamentals Late data challenges Stream window types