Sliding Windows

Hopping windows advance at fixed intervals. Tumbling windows fire once per bucket. Sliding windows fire on every arriving event, continuously recalculating an aggregate over the most recent N events or T time units. That sounds expensive because it is. The entire engineering story of sliding windows is making the per event cost O(1) instead of O(window_size).

Netflix monitors quality of experience per CDN pop using a 10 minute sliding window updated every 10 seconds. If a pop's rebuffer ratio spikes, the control plane reroutes traffic to a healthy pop. That 10 second refresh means a degradation is caught within 10 seconds of crossing the threshold, not after 10 minutes. For a service that streams to 200 million subscribers, those 10 seconds of faster detection translate directly into fewer playback interruptions.

The reason sliding windows exist separately from hopping windows is the continuous output. A hopping window fires once per hop. A sliding window fires on every event (or on every slide interval, depending on the framework). For anomaly detection, fraud scoring, and quality monitoring, the difference matters: you detect a threshold crossing as soon as it happens rather than waiting for the next hop.

By the end of this lesson you will understand the naive versus pane based implementation, why the naive version melts under load, and how pane state turns sliding windows from a theoretical concept into a production pattern.

The difference between a sliding window that works and one that collapses under load comes down to one architectural decision: do you rescan the buffer on every event, or do you maintain partial aggregates per pane?