Count-Based Windows

Sometimes you do not care about time at all. An ML inference endpoint wants exactly 1000 feature vectors per batch because the model was optimized for that batch size. A bulk Elasticsearch sink wants exactly 500 documents per request because that is where throughput peaks and fewer requests means fewer round trips. A rate limited third party API charges per call and you want to pack as many records as possible into each call.

For all of these, time based windows are the wrong tool. A 1 minute tumbling window might fire with 3 events on a quiet Sunday or 50,000 events on a Friday peak. Neither matches the downstream consumer's preferred batch size. Count based windows close after exactly N events regardless of how long that takes, giving the downstream consumer a predictable payload size every time.

The trap that catches every team deploying count based windows for the first time is the quiet period. If a key stops producing events, the partial window sits in state forever and never fires. A product active during European business hours accumulates 300 events on Sunday evening and holds them in state until Monday morning. Any freshness guarantee is dead. The fix is a composite trigger that fires on count OR time, whichever comes first, so low traffic periods still emit within a bounded latency.

By the end of this lesson you will understand how count based windows fire, why the time fallback is mandatory, and how to size the composite trigger for variable traffic patterns.

The choice between count and time comes down to what your downstream consumer cares about: consistent batch size or consistent freshness. This comparison captures the properties side by side.