Time Series Forecasting • Real-time Updates (Online Learning, Sliding Windows)Easy⏱️ ~2 min
What Are Sliding Windows in Real Time Systems?
Sliding windows are a fundamental technique for computing aggregates over the most recent subset of data in streaming systems. Instead of processing the entire history of events, you maintain only a fixed time period (like the last 5 minutes) or count (like the last 1000 events). This bounded computation makes systems responsive to current behavior while keeping memory usage predictable.
The key insight is incremental updates. Rather than recalculating the entire aggregate every time a new event arrives, you subtract the contribution of events leaving the window and add the contribution of new events entering. This reduces the cost from O(window size) per event to O(1) per event. For example, to maintain a sum over the last 1000 values, you simply subtract the 1001st oldest value and add the newest value.
In production, companies use different window types for different use cases. Tumbling windows are fixed, non overlapping periods like 1 minute buckets for computing rates. Hopping windows overlap by advancing in smaller steps, such as a 1 hour window that moves forward every 5 minutes to create smooth trend lines. Session windows group events by inactivity, such as treating clicks within 30 minutes as one shopping session. The choice depends on whether you need discrete time boundaries, smooth transitions, or behavior based grouping.
The critical decision is event time versus processing time. Event time uses the timestamp embedded in the event itself, which correctly handles out of order delivery but requires watermarks to know when a window is complete. Processing time uses the clock when the system receives the event, which is simpler and lower latency but miscounts when events arrive late due to network delays or mobile devices coming back online.
💡 Key Takeaways
•Sliding windows bound computation to recent data, typically last N minutes or last K events, reducing memory from unlimited history to O(window size)
•Incremental updates achieve O(1) cost per event by subtracting exiting values and adding entering values instead of recomputing entire aggregate
•Event time windows use timestamps from events themselves and handle out of order delivery correctly, while processing time windows use system clock for simpler but less accurate semantics
•Common window types serve different needs: tumbling for discrete rates, hopping for overlapping trend analysis, and session windows for grouping by user inactivity gaps
•Production systems at Uber and Airbnb compute features like last 5 minute click rate or last hour unique categories using sliding windows with end to end latency under 300 milliseconds
📌 Examples
Rate limiting: Track failed login attempts in a 1 minute tumbling window per user, block after 5 failures. At 500K events/sec, partition by user ID to keep per partition load under 5K events/sec.
Fraud detection: Maintain sliding 10 minute window of payment attempts per card with count and sum. Detect anomalies when count exceeds 20 or sum exceeds $5000, with p99 detection latency under 1 second.
Real time CTR: Compute clicks divided by impressions over last 15 minutes with 1 minute hops. For an ad with 1000 impressions/min, store 15 buckets of (clicks, impressions) pairs, roughly 240 bytes per ad.