High-Level Design
Why this matters: the whole system reduces to three components. Getting that skeleton on the board fast leaves time for the parts that are actually hard — collection strategy and scale.
Key takeaway
The monitoring service comprises storage (a time-series database), a data collector service that fetches and persists metrics, and a querying service that reads them back.
The three components
| Component | Responsibility |
|---|---|
| Storage | A time-series database stores metric data, such as CPU usage or application exceptions |
| Data collector service | Fetches relevant data from services and persists it to storage |
| Querying service | An API that queries the time-series database to retrieve data |
Note the two different arrows into the collector — fetch from services and servers, push from applications. That mixed model is not accidental, and Lesson 4 is about why.
Why a time-series database
Metrics are a specific data shape, and TSDBs exist because general-purpose databases handle it badly:
| Property of metric data | Consequence |
|---|---|
| Append-only, ordered by time | Writes always land at the newest end — no random updates |
| Enormous write volume, modest read volume | Write throughput dominates the design |
| Queried by time range, not by key | "CPU on node X over the last hour", not "row 42" |
| Value declines with age | Old data can be downsampled or dropped — unusual among databases |
| Highly compressible | Consecutive samples differ slightly; delta encoding wins hugely |
The building block reused
What this skeleton is missing
Deliberately, at this stage:
- Where the collector gets its target list — services scale up and down constantly (Lesson 5).
- How alerts are configured and fired (Lessons 3 and 6).
- What happens past one monitoring server — this design has an obvious single point of failure (Lesson 7).
Key takeaway
Collect, store, query. Three components is the right first diagram — and each of the three grows a subsystem once you ask how it works at fleet scale.
Interview signal by level
| Level | What a strong answer sounds like |
|---|---|
| L4 | "A service collects metrics and stores them in a database." |
| L5 | Names the storage choice: "a time-series database, because metrics are append-only and queried by time range." |
| Staff+ | Justifies the TSDB from the data shape: "write-dominated, time-ordered, highly compressible, and the value decays with age — so the store can downsample old data, which a general-purpose database won't do for you." |
Next: the three stores this actually needs.