You are designing the simplest database that can stomach a metrics firehose: 10,000 hosts each emitting 50 numbers every 15 seconds, forever, without losing precision and without needing a rack of disks. Clients push points in (scrape), or run PromQL-shaped queries pulling them out (sum(rate(metric{labels}[range]))); the engine packs every sample into a few bits on disk and answers a 5-minute alert in single-digit milliseconds.

Prometheus and Gorilla are the canonical worked examples. Once you build the core, the design space of every metrics store collapses to a handful of named trades — the bits-per-point you accept, the cardinality budget you defend, the depth-of-retention you afford, and where you put the line between "single-node" and "somebody else's problem."

Resist the urge to "describe Prometheus." Make decisions yourself, defend them, and let the workload push back. The point is to feel why each price is paid and which workload pays it.