Stream Processing Window Types

Compare tumbling, sliding, session, and count windows on the same IoT event stream.

animation
stream-processing
data-analytics
event-time
watermarks
interactive
Interactive stream windowing lab showing deterministic event tokens, window assignment, sliding fan-out, keyed session grouping, watermark and late-data policy, formulas, and responsive learning support.
Stream processing Window assignment Event time Late data

Watch one IoT event stream fall into different window types.

The same sensor readings produce different results depending on whether the processor uses fixed non-overlapping windows, overlapping rolling windows, activity sessions, or count-based batches. Step through arrivals and compare the window rule, fan-out, watermark decision, and emitted aggregate.

Tumbling Window rule
1 window Active assignment
0 late Late or side output
4.0s wait Close estimate
What moves The active event token moves from event timestamp to arrival time, then into its selected window or side output.
What changes Window membership, fan-out, retained state, and output timing update from the same deterministic event trace.
What to compare Tumbling counts once, sliding can count several times, sessions follow activity gaps, and count windows ignore time boundaries.
Common trap Watermark delay and allowed lateness are related but not identical; one delays closure, the other controls late updates.

Factory temperature stream

Regular machine telemetry demonstrates fixed tumbling boundaries and one event per window.

Assigned
Windows Event time Arrival
watermark 0.0s
A
1. Stamp The device timestamp decides event-time membership.
2. Arrive The processor receives the event in arrival order.
3. Assign The active rule maps the event to one or more windows.
4. Emit The window updates, closes, or routes late data aside.
A at 1.0s Event timestamp
Arrives 1.4s Processing time
[0.0s, 5.0s) Assigned window

Event A is assigned to one tumbling window because its timestamp is inside a fixed non-overlapping interval.

Window Type Reference
Type Rule Useful for
Tumbling Fixed, non-overlapping intervals. Each time event belongs to exactly one window. Periodic reports, billing intervals, dashboard buckets.
Sliding or hopping Fixed-size windows advance by a slide interval. One event can be copied into several overlapping windows. Moving averages, trend detection, rolling anomaly checks.
Session Keyed windows stay open while events for that key are separated by no more than an inactivity gap. Trips, user sessions, bursty device activity.
Count A result is formed after a configured number of accepted records rather than after a time boundary. Payload batches, small sample groups, bounded edge buffers.
Formulas And Labels
  • Tumbling: start = floor(t / size) * size, window is [start, start + size).
  • Sliding: valid starts satisfy start <= t < start + size and start mod slide = 0.
  • Session: events for the same key merge while next_event_time - previous_event_time <= gap.
  • Watermark: this teaching model uses max_event_time_seen - watermark_delay. Production systems may compute watermarks per partition or source.
  • Late event: an event is late when its event timestamp is behind the current watermark; it may still update a window if allowed lateness keeps the window state.
Design Tradeoffs
  • Tumbling windows keep state small and avoid double counting, but their results update only at each window boundary.
  • Sliding windows improve trend visibility but multiply state and compute roughly by ceil(window_size / slide_interval).
  • Session windows fit sparse activity but need keyed state and can merge when late events bridge two earlier sessions.
  • Large watermark delays improve completeness but delay output. Large allowed-lateness values retain state longer and create correction traffic.
Production Notes
  • Kafka Streams often calls fixed overlapping time windows "hopping windows"; many courses also use "sliding" for the same visual idea.
  • Processing-time windows are simpler but can misplace delayed sensor readings because arrival time is not the physical measurement time.
  • Very late events should not disappear silently. Route them to side output, audit storage, replay, or a correction workflow.
  • Exactly-once output depends on source offsets, state store updates, and sink writes being committed consistently; window choice alone does not guarantee it.
Stream processing fundamentals Event time vs processing time Stream processing game Late data challenges