# Design a Time-Series Database Design a database for ingesting and querying timestamped measurements. A data point belongs to a logical series identified by a metric name and a set of labels, and contains a timestamp and numeric value. Support sustained writes, time-range queries over one or more series, configurable retention, and optional downsampled views. Clarify ordering, duplicate timestamps, late data, precision, label cardinality, consistency, and expected query shapes before choosing components. ### Constraints & Assumptions - Workload scale and latency targets are intentionally unspecified and must be elicited. - Recent data is read more often than old data. - Nodes and disks can fail; acknowledged data needs a defined durability guarantee. - Arbitrary high-cardinality labels can make indexing unbounded. ### Clarifying Questions to Ask - What are ingest rate, active-series count, retention, and value precision? - Are points append-only, or can old timestamps be corrected? - Which label filters, aggregations, and groupings dominate queries? - How fresh and how exact must raw and downsampled results be? ### What a Strong Answer Covers - Series identity, partitioning, write path, and immutable storage layout - Label indexing and cardinality controls - Query planning, caching, compaction, retention, and downsampling - Replication, deduplication, late writes, and recovery - Capacity reasoning, hotspots, observability, and trade-offs ### Follow-up Questions - How do you prevent one high-volume series from becoming a hot partition? - How do corrections reach already downsampled data? - What happens when labels change on every event? - How would you restore service after losing a storage node?