Design a Time-Series Metrics Store

Data, Storage & ConsistencyMediumdesign-time-series-store

Design storage for a billion metric points an hour: append-only writes, range queries over arbitrary windows, and a cardinality problem that will eventually try to kill you.

LSM TreesDownsamplingRetention TiersDelta EncodingCardinality Control

Traffic & Capacity Estimates:

2M data points/second · 10M active series · 13-month retention · sub-second range queries

Functional Requirements

•Ingest timestamped points tagged with labels, ordered roughly but not strictly by time.
•Query by label matchers over a time range with aggregation (rate, percentile, sum by tag).
•Downsample older data to coarser resolution automatically as it ages.
•Drop data past the retention horizon without a full rewrite.

Non-Functional Requirements

•Ingest must never block on query load — write path and read path are isolated.
•Range query over 24 hours of one series returns in under 500ms.
•A cardinality explosion from one bad label must be contained, not fatal.

Back-of-the-Envelope Math

2M points/s * 16 bytes raw = 32 MB/s; delta-of-delta plus XOR compression gets this near 1.5 bytes/point.
10M series * 13 months at 1-minute resolution, downsampled after 15 days, is the difference between ~70 TB and ~7 TB.

Key Architectural Trade-offs

LSM-tree/columnar chunk storage optimised for append vs a B-tree store — time-series workloads are 99% writes and never update in place.
Downsampling makes long-range queries affordable and permanently destroys the resolution you'd want during an incident postmortem.
Unbounded label cardinality (user IDs, request IDs as tags) is the classic outage; enforcing limits at ingest is unpopular and correct.

Click or drag a component onto the canvas, then connect the handles to draw the data flow.

3 nodes · 2 edges

Components · 35

Client & Edge4

Compute & Gateway7

Storage & Caching11

Messaging & Streaming6

Coordination & Ops5

Intelligence2

React Flow