Tumbling vs Sliding vs Session Windows: Picking the Right Shape for Stream Aggregates

Windowing in stream processing looks like a configuration question and is actually a modeling question. The window you pick decides what your aggregates mean. Get the shape wrong and your dashboards lie in subtle ways.

There are three primitives worth knowing.

Tumbling windows cut the timeline into non-overlapping fixed buckets. A five-minute tumbling window has the buckets [12:00, 12:05), [12:05, 12:10), and so on. Every event lands in exactly one window. This is the right shape when each bucket has standalone meaning. Hourly revenue for billing. Daily active users. Per-minute error counts feeding a status page. The result for one bucket does not depend on any other bucket.

Sliding windows have a fixed duration plus a slide interval shorter than the duration. A five-minute window that slides every thirty seconds emits an aggregate every thirty seconds covering the most recent five minutes. Events appear in multiple windows. This is the shape for smooth rolling statistics: anomaly detection on a moving average, p99 latency over the trailing minute, fraud rules that fire when the request rate over the last sixty seconds exceeds a threshold. Tumbling windows would give you a sawtooth on those metrics. Sliding windows give you a curve.

Session windows are gap-driven instead of time-driven. A session ends when no events arrive for a configured inactivity gap. The bucket size is whatever the user's actual burst of activity was. This is the right shape for anything tied to user behavior: a search session, a shopping cart, a game match. You cannot pick a fixed duration because the question itself is "how long did this person stay engaged."

Now the part that makes windowing hard.

Stream processors see two clocks. Event time is the timestamp on the event itself, set when it was produced. Processing time is the wall clock when the event hits the processor. Real systems have network delays, mobile clients buffering offline, broker rebalances, replays. Events arrive late and out of order all the time.

Watermarks are the framework's estimate of how far event time has progressed. When the watermark crosses the end of a window, the framework closes that window and emits the result. Late events that arrive after the watermark either get dropped, get routed to a side output, or trigger a window update if you configured allowed lateness.

Concrete example. You run hourly tumbling windows for billing and a thirty-second-slide five-minute sliding window for anomaly detection on the same event stream. A mobile client uploads two hours of buffered events. Your billing aggregate for the affected hour is now wrong unless you allowed late updates. Your anomaly window already moved past and shows a quiet period. Same data, two answers, both technically correct for what the window meant.