Skip to content

CONCEPT Cited by 1 source

Rolling-window query

Definition

A rolling-window query is a time-series query whose window advances continuously with clock time — typically [now - Δ, now] for some rolling window Δ (last 3 hours, last 5 minutes, last 24 hours). The start and end of the query interval both shift forward every refresh. Most of the data inside the window is unchanged from the previous refresh; only the newest tail is genuinely new.

Why it's a caching hard case

Conventional result caches key the cache on (query, interval). A rolling-window query shifts the interval every refresh, so every refresh is technically a different cache key — even though 99%+ of the underlying data is identical to the previous request. Result: cache misses on every refresh, and the backend database answers nearly-identical queries at the full dashboard refresh rate.

Netflix's Druid cache post frames this explicitly (Source: sources/2026-04-06-netflix-stop-answering-the-same-question-twice-interval-aware-caching-for-druid):

"If the time window shifts even slightly, the query is different, so it's a cache miss."

Why it's common in production

Rolling-window queries are the dominant shape in operational dashboards at companies with real-time analytics. Examples:

  • Live-show monitoring dashboards — during a high-profile launch, engineers watch a "last 3 hours" view refresh every 10 seconds.
  • Canary analysis — new service version's metrics over the last N minutes, compared to a baseline.
  • A/B test monitoring — test vs control metric panels over the last few hours.
  • Automated alerting — "error rate over last 5 minutes > X."

At Netflix one popular dashboard has 26 charts generating 64 queries per load, refreshes every 10 seconds, and with 30 concurrent viewers emits ~192 queries/sec — mostly for the same underlying data (Source: sources/2026-04-06-netflix-stop-answering-the-same-question-twice-interval-aware-caching-for-druid).

The structural fix

Interval-aware caching keys the cache on query shape (without the interval) plus time-bucket coordinates separately. Shifted windows then reuse the buckets they share with the previous window; only the new tail misses. See Netflix's Druid interval cache for the canonical wiki instance.

Relationship to other time-based query shapes

  • Fixed-window query: [t1, t2] where t1 and t2 are literal timestamps ([2026-04-01, 2026-04-06]). Cache-friendly under any shape of cache — the key is stable.
  • Rolling-window query: [now - Δ, now]. Cache key shifts every refresh. The problem this page describes.
  • Sliding-window aggregation (streaming compute sense): the query shape is similar but the compute model is continuous / push; the caching discussion applies more to the pull / refresh dashboard shape.

Seen in

Last updated · 319 distilled / 1,201 read