How would you design a metrics monitoring and alerting system?
0 views
100 of 106
1
The problem
Question presented to candidate:
"Design a metrics monitoring and alerting system for a company running a few hundred services: something like Prometheus plus Alertmanager, or Datadog. It must collect metrics from every service, keep them for a year, power dashboards, and page the on-call engineer when users are affected, without paging them for noise."
What a strong answer should cover:
Data model: metric name plus labels identifies a time series of (timestamp, float) samples; counters, gauges, histograms; cardinality as the main scaling limit, with worked numbers
Collection: pull (scrape) vs push, service discovery, agents; ingest sharded by series hash with replication
Storage: an in-memory head with a WAL, immutable compressed blocks (delta-of-delta timestamps, XOR values), object storage for history, downsampling and retention
Query: range and instant queries, rate() over counters, percentiles from histograms, caching for dashboards
Alerting: rule evaluation with for durations; SLO burn-rate alerts over multiple windows instead of raw thresholds; Alertmanager-style grouping, deduplication, inhibition, silences and routing
Reliability of the monitor itself: HA pairs, meta-monitoring and a dead man's switch alert
Clarifying questions expected:
How many services, instances and series, and at what scrape interval and retention?
Pull or push, and multi-tenant or single team?
What should page a human, and what should only create a ticket?
Code / implementation expected: Optional โ the examples simulate burn-rate alerting against a naive threshold, compute cardinality, and count compression bits.
system-design
case-study
2
Try it yourself
Sketch your approach before you read the solution. That is what the interview tests.
Stuck? Get a hint.
A short nudge toward the approach. It will not give the answer away.
3
Solution
Target Audience: Engineers who use dashboards and alerts every day and want to understand how the system behind them is built, and candidates facing a "design Prometheus / Datadog" round.
Difficulty: Hard
Verified with: Node 22.22, Python 3.12, Go 1.24 and Java 21 for the alerting example (identical output), Node 22.22 and Python 3.12 for the compression example. Burn-rate thresholds are those of the Google SRE Workbook chapter "Alerting on SLOs" as reproduced by Last9, Pydantic Logfire and Grafana articles; Alertmanager defaults (group_wait 30s, group_interval 5m, repeat_interval 4h) and Prometheus scrape defaults (interval 1m, timeout 10s) from prometheus.io configuration docs; the 1.37 bytes per point figure from the Facebook Gorilla paper (VLDB 2015).
How to read this doc: Every idea is explained in plain language first, then tagged with ๐ Interview term:
The solution is hidden so you can try first
21 min read ยท 15 sections
4
Read the code
SLO alerting: a naive threshold vs multiwindow, multi-burn-rate alerts on four failure shapes, plus label cardinality arithmetic