How the interviewer opens it
“Design a database for timestamped measurements. It must support high write rates, time-range aggregates, retention policies, and downsampling.”
The prompt is vague on purpose. The first minutes are for you. Reduce the prompt to the core features and agree on the numbers before you draw.
What to clarify first
- Measurement format
- Write scale
- Read scale and latency
- Query behavior
- Late samples and retries
- Retention and historical queries
- Freshness and availability
- Durability and deployment
- Tenants
- Design boundary
The interviewer has the answers. In a SysRound round, Alex gives these answers, as a real interviewer does.
Scope of a strong answer
Core requirements
- Accept timestamped measurements with metric names and labels
- Query samples and aggregates by labels and time range
- Apply retention policies to raw samples
- Keep lower-resolution aggregates for longer periods
Usually out of scope
- Client agents and measurement collection
- Alert rules
- General SQL and joins
- Cross-region writes
- Changes to accepted sample values
What interviewers ask about
- Write acceptance and recovery
- The database accepts millions of samples each second. It must preserve acknowledged data without counting retries across memory, stored data, or recovery.
- Label-filtered queries
- Label filters select data across millions of series. Large tenants and unique label values can exhaust indexes and query resources.
- Late samples and historical results
- Late samples can change recent totals. Fixed-resolution history cannot answer arbitrary time boundaries or steps exactly.
- History expiry and storage work
- History expiry and aggregate tasks compete with writes. Their failures can cause storage growth or permanent gaps in old results.
Common mistakes
- Partitioning only by timestamp and concentrating all current writes on one machine
- Ignoring label cardinality and the cost of series indexes
- Acknowledging writes before the required durable copies exist
- Counting retry copies from memory and stored data as separate samples
- Promising arbitrary historical boundaries and steps from fixed five-minute aggregates
- Deleting raw samples without checking aggregate coverage or reporting history gaps
The bar by level
- Senior (L5/E5)
- Defines shard ownership, durable recovery, and bounded queries. Preserves sample uniqueness across storage states. Handles late samples, aligned history, and expiry.
- Staff (L6+/E6+)
- Defines failure contracts for zone loss and history gaps. Quantifies storage, index, and scan costs. Controls tenant load and background work during failures.