Design the rollup layer of a time-series metrics backend. High-cardinality metric samples pour in continuously; your system aggregates them into coarser time buckets (downsampling / rollups) and serves range queries at whatever resolution fits the query window, so a dashboard stays fast whether it shows the last 5 minutes or the last year.

Operating context. Samples arrive as (metric, labels, timestamp, value) at roughly 10,000,000 samples/sec, spread over up to 50,000,000 active series. Raw data is kept at full resolution for 24 hours, rolled up to 1-minute for 7 days, and to 1-hour for 400 days. A query names a metric and a time range; the service picks the coarsest resolution covering that window. Rollups computed are sum, count, min, and max (average is derived).

Out of scope. The collection agent and the push/scrape protocol, alerting and rule evaluation, the dashboard query language, and any long-term archival format. Assume those are owned elsewhere.

What to produce. A high-level architecture covering: ingest and how a sample resolves to a stable series identity under high cardinality; the rollup pipeline (windowed aggregation — what is computed and when a window closes); the storage layout that supports reads across multiple resolutions; the query path that selects a resolution and stitches raw plus rollup at the boundary; and how late or out-of-order samples are handled. Sketch the components and the flow; we will probe specifics in checkpoints.