Tumbling and Sliding Windows

Analogy categoryAnalogies

Tumbling Windows: Fixed, Non-Overlapping Buckets

A tumbling window divides the event-time (or processing-time) axis into consecutive, non-overlapping, fixed-length intervals — for example, TumblingEventTimeWindows.of(Time.minutes(5)) creates windows [00:00, 00:05), [00:05, 00:10), and so on. Every event belongs to exactly one tumbling window, determined purely by its timestamp modulo the window size, so there is no double-counting and no gap between windows. This makes tumbling windows the natural choice for periodic reporting use cases like 'requests per minute' or 'revenue per hour,' where each time bucket should be summarized independently and exactly once.

🏏

Cricket analogy: A tumbling window is like reporting a team's score over-by-over: each over (0-6 balls) is its own bucket, no ball counts toward two overs, and the over-6 tally is finalized independently before over-7 begins.

Sliding Windows: Overlapping, Recomputed Intervals

A sliding window also has a fixed length, but it advances by a slide interval smaller than the window size, so consecutive windows overlap and a single event can belong to multiple windows simultaneously. SlidingEventTimeWindows.of(Time.minutes(10), Time.minutes(1)) creates 10-minute windows that start every 1 minute, meaning any given event contributes to up to ten different windows. This is the right tool for smoothed, continuously-updated metrics like a rolling 'last 10 minutes' moving average that refreshes every minute, at the cost of roughly (window size / slide interval) times more computation and state than a tumbling window of the same length.

🏏

Cricket analogy: A sliding window is like a commentator reporting a batter's 'run rate over the last 10 balls,' recalculated after every single ball — ball number 47 counts toward the window ending at ball 47, 48, 49, and so on, up to ten overlapping windows.

Choosing Between Them and Cost Implications

The core decision is simple: use a tumbling window when you need a clean, non-overlapping partition of time (billing periods, daily reports, per-minute counters), and use a sliding window when you need smoothed, continuously refreshed metrics that react quickly to recent data (rolling averages, anomaly detection over 'the last N minutes'). The state and compute cost difference is significant — a sliding window with window size W and slide S keeps roughly W/S times more window state per key than a tumbling window of size W, because each incoming event is replicated into every overlapping window it belongs to; a 1-hour sliding window with a 1-minute slide means each event is assigned to 60 concurrent windows.

🏏

Cricket analogy: Choosing a tumbling per-over scorecard versus a rolling last-10-ball run-rate ticker is exactly this trade-off: the scorecard is cheap to maintain since each ball touches one over, while the rolling ticker recomputes constantly and costs more to keep live.

java

// Tumbling window: non-overlapping 5-minute revenue buckets
DataStream<Order> orders = ...;

orders
    .keyBy(Order::getStoreId)
    .window(TumblingEventTimeWindows.of(Time.minutes(5)))
    .aggregate(new SumRevenueAggregate());

// Sliding window: rolling 10-minute average, refreshed every 1 minute
orders
    .keyBy(Order::getStoreId)
    .window(SlidingEventTimeWindows.of(Time.minutes(10), Time.minutes(1)))
    .aggregate(new AverageRevenueAggregate());

Both window types support an optional offset parameter (e.g., TumblingEventTimeWindows.of(Time.hours(1), Time.minutes(-30))) to align window boundaries with a non-UTC business day or a timezone that isn't aligned to the hour.

A sliding window's state grows with window-size divided by slide-interval; an aggressive 24-hour window with a 1-second slide creates 86,400 concurrent overlapping windows per key and can exhaust state backend memory — always sanity-check this ratio before deploying.

Tumbling windows are fixed-length, non-overlapping buckets — every event belongs to exactly one window.
Sliding windows are fixed-length but advance by a smaller slide interval, so events belong to multiple overlapping windows.
Use tumbling windows for clean periodic reports; use sliding windows for smoothed, continuously refreshed metrics.
Sliding window state and compute cost scale roughly with window-size divided by slide-interval.
Both TumblingEventTimeWindows and SlidingEventTimeWindows support an offset parameter for timezone or business-day alignment.
An overly fine slide interval on a large window can cause state backend memory pressure.
Window assignment can be based on event time or processing time depending on the WindowAssigner chosen.