We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
2 system design questions lean on this idea. Each walks through the full answer.
System Design Masterclass · Stream Batch Processing
Free preview: the first part of this 6-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Stream Batch Processing
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
It is easy and good
“It is really nice and good Please join the course”
When someone says windowed aggregation in a streaming context, they almost always mean tumbling windows whether they know it or not. Count events per minute. Average per hour. Total bytes per 10 second slice. Every time a metrics pipeline emits one number per time bucket, that is a tumbling window underneath.
The definition is brutally simple. Fixed size, non overlapping, aligned on a common boundary. A 60 second tumbling window creates buckets at [10:00:00, 10:01:00), [10:01:00, 10:02:00), [10:02:00, 10:03:00), and so on. Every event belongs to exactly one bucket based on its event timestamp. When the watermark crosses the end of a bucket, the bucket fires its aggregate and its state is cleared.
The reason tumbling is the default shape is that it has the smallest memory footprint and the cleanest semantics. Sliding and hopping windows keep multiple overlapping buckets in state at once, which multiplies memory usage by the overlap factor. Session windows have variable sizes that depend on event gaps. Tumbling windows have exactly one active bucket per key at any time, and the state is bounded by the number of active keys times the event volume per bucket.

The top line is one stream of 40 events. The three lanes below carve that same line, and the events never move.
Tumbling is the only one whose counts add up to the stream. Six windows: 15 plus 3 plus 9 plus 2 plus 5 plus 6, and that is 40. Every event is in exactly one bucket, which is why the state is one open window per key and why this is the default.
Hopping counts the same 40 events 71 times. Twelve windows, each ten seconds long, starting every five. Every event falls in two of them, so memory and emission rate both roughly double. Notice that the top hopping row is exactly the tumbling boundaries and the bottom row is those windows shifted by five seconds, which is the clearest way to see that hopping with an advance equal to its size is tumbling.
Session windows have no fixed width at all. They open on an event and close after six seconds of silence, so their lengths here are 13, 12 and 9 seconds, plus one holding a single event and therefore no duration. Nothing about the clock decided those boundaries. The data did.
Which is the real choice you are making. Tumbling answers "how many per minute". Hopping answers it more often and pays twice over, in state and in output. Session answers something else entirely, "how long was the visit", and it is the only one of the three whose windows cannot be planned in advance.
Tyler Akidau's Streaming 102 walks through every window shape and keeps coming back to tumbling windows as the baseline. Every metric pipeline at Netflix, Uber, LinkedIn, and Stripe uses tumbling windows for their per minute and per hour aggregations. By the end of this lesson you will understand exactly how Flink assigns events to buckets, how watermarks trigger firing, and how to handle late arrivals without losing data or blowing up memory.