Interval-aware caching for Druid

At scale, analytical query systems hit the same pattern: identical time-range queries fired over and over by dashboards, scheduled jobs, and ad-hoc exploration. When each one traverses the full compute path, it burns cycles re-deriving answers the cluster already produced minutes ago. This is a walkthrough of an interval-aware caching layer we built on top of Druid: it cuts the redundant work sharply while keeping results correct as data arrives late.

The problem

Druid is optimised for slicing time-series data by interval. A typical dashboard query asks for metrics over the last 24 hours, the last 7 days, or a specific business window. Two queries that differ by a few seconds of range still require independent scans, even though 99% of the underlying segments are shared.

A naive whole-query cache fails here for two reasons:

• Query keys rarely match byte-for-byte: dashboards constantly shift their time windows forward.
• Partial invalidation is awkward. When late-arriving data lands in a segment, any cached answer that overlaps it must be recomputed.

A whole-query cache treats two near-identical questions as strangers. The shared 99% pays full price on every call.

Interval-aware keys

Instead of caching the full query result, we decompose each query into closed and open intervals. Closed intervals point at segments Druid has already sealed; these are safe to cache indefinitely. Open intervals cover the live edge of the data and are always recomputed from source.

A simplified key derivation looks like this:

def cache_keys(query, segments):
    closed, open_ = [], []
    for seg in segments.covering(query.interval):
        if seg.is_sealed():
            closed.append(("seg", seg.id, seg.version, query.agg))
        else:
            open_.append(seg)
    return closed, open_

Once a segment is sealed, any aggregate over it is a pure function of the segment id. That is a cache hit reusable across every dashboard asking the same question.

Late arrivals and correctness

Real-world pipelines don't always deliver events in order. To handle this, each cached interval records the segment version it was computed against. When a segment is replaced, by compaction, late events, or re-ingestion, the cache entry is invalidated atomically.

on_segment_replaced(old_id, new_id):
    for key in cache.scan(prefix=("seg", old_id)):
        cache.delete(key)
    metrics.inc("cache.invalidations")

Results

After rolling this out across the analytics fleet we observed:

• Query latency dropped by roughly 70% on cache-friendly workloads.
• Druid broker CPU usage fell by a double-digit percentage during peak dashboard hours.
• Cache correctness incidents went to zero: the interval versioning caught every late-arrival case automatically.

What's next

We're exploring adaptive TTLs on open intervals based on observed event-arrival patterns, and a shared cache layer across regions so a rebuilt dashboard in one datacentre warms the others. If you operate analytics systems at scale and want to compare notes on interval caching, reach out.