Metrics & Monitoring at Scale
hardOpen designCommonly asked~45 minHLD roundBar raiserSenior / SDE-3AmazonGoogleMicrosoftNetflixAtlassianUberObservabilityStreaming & Real-time DataStorage & Data ModellingCapacity & Estimation
The question, as asked
“Design the system behind our dashboards and alerts. Thousands of services emitting metrics, graphs that load instantly, and alerts that fire within a minute.”
Scope it before you design it
The prompt is vague on purpose. These are the clarifying questions a strong candidate asks first — answer them out loud before you touch the architecture.
- Metrics only, or logs and traces too? They have completely different storage shapes. Scope to metrics and say you'd treat logs and traces as separate systems — that's the correct answer, not a dodge.
- Cardinality is the whole game: how many distinct time series? Ask for the number of metrics times the number of label combinations, because that number — not the event rate — is what kills these systems.
- Retention: how long at full resolution, and how long downsampled? Nobody needs per-second data from last year, and saying so early saves most of your storage.
- Push or pull? A pull model (scrape) gives you a free liveness signal and natural rate limiting; push handles short-lived jobs and NAT'd clients. Worth a sentence on which and why.
- Alert latency requirement — within a minute changes the design, because alerts then can't be evaluated by querying stored data.
- Who writes the queries? Engineers exploring ad hoc, or fixed dashboards? Fixed dashboards can be precomputed; exploration can't.
Your answer, first
Commit something before anything unlocks. Saved on this device as you go.
0 charactersExpand for room to draw
Framework hint
Sketch or write your approach above first. The hint gives you the structure, not the answer.