Question
Design the series-indexing layer (not the sample storage) of a metrics TSDB facing a cardinality explosion: metrics are identified by a name plus key/value labels (e.g., http_requests{route, status, pod, region}), and an operator accidentally added a high-cardinality label (request_id, user_id) so active series jumped from 2M to 80M, then those series churn (pods come and go, so series are born and die constantly). Queries select series by label matchers ('all series where route=/checkout and status=5xx') and must resolve to the matching series set fast. Design how series are identified, indexed by labels, and how you survive churn and cardinality.
Clarify scale and constraints first. Propose a clean component breakdown, then go deep on the hard parts — data model, bottlenecks, consistency, failure modes — and name the trade-offs you are making.