YOUR BRIEF
What to work through
Work through a metrics monitoring system as a spoken system design interview. Start by clarifying the scope, sketch a working design and explain the trade-offs behind your choices.
- Collect operational metrics (CPU, memory, disk, requests per second) from every server
- Store them as time series and answer queries over any time range
- Fire alerts by email, phone, PagerDuty and webhooks when a rule matches
- Show metrics and alerts on dashboards
BEFORE YOU START
Constraints to discuss
- About 10 million metrics: 1,000 pools of 100 machines, about 100 metrics each
- One-year retention: raw for 7 days, 1-minute resolution to 30 days, 1-hour after
- Recent data is fast to read: about 85% of queries ask for the last 26 hours
- No missed critical alert: each one reaches its channel at least once
Need a starting point?
Watch for these common gaps as you prepare:
- Storing data points in a general relational database
- Labels with many unique values, such as user ids, that explode the number of series
- Collectors writing straight to the database with no buffer, so an outage loses data
- Alerts with no dedup, so one incident pages many times
- Drawing every box in detail instead of going deep on one or two components
Why this question is in the collection
These sources connect the problem to company interview reports or preparation guides. They do not guarantee what a company will ask you.
- Google: Hello Interview’s Google L5 guide puts “Design a global VM monitoring system” third on its most commonly asked list.
- OpenAI: PracHub lists “Design a metrics monitoring system, going deep on one or two components” (Oct 1, 2026), and power grid device monitoring variants with late and duplicate events.