Design a Cache for a DAG of Materialized Views
Views are defined over base tables and over other views, forming a DAG. Design the cache that serves materialized results for these views so that a query reads a fresh-enough result quickly, a change to a base table is reflected in every view that depends on it, and the recompute cost stays bounded.
Cover the cache key, how refreshes are ordered, how a query over several views sees consistent data, storage tiers and tenant limits, and what happens when many queries miss at once.
Hints
Hint 1
Key each entry by the view id, a hash of its definition, and the snapshot version of every input — a changed input produces a different key, so stale entries are simply never read.
Hint 2
Refresh in topological order so a view is rebuilt after its inputs; pin one snapshot per query so views joined together agree.
Hint 3
Tiers: memory, local SSD, a shared cache; per-tenant quotas; single flight so one recompute serves many concurrent misses.
Asked at
Sign in to talk to the interviewer — ask what's in scope, what scale to design for, or for a nudge when you're stuck. Conversations save to your account.