# Design a time-series database like InfluxDB: system design interview question

> High-rate measurements with label filters, time-range aggregates, retry-safe counts, and retained history at lower resolution.

Source: https://sysround.com/questions/design-time-series-database-like-influxdb
Updated: 2026-11-05


Difficulty: hard. Levels: Senior, Staff+.

## How the interviewer opens it

"Design a database for timestamped measurements. It must support high write rates, time-range aggregates, retention policies, and downsampling."

## 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

## 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 probe

### 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:** Defines shard ownership, durable recovery, and bounded queries. Preserves sample uniqueness across storage states. Handles late samples, aligned history, and expiry.
- **Staff+:** Defines failure contracts for zone loss and history gaps. Quantifies storage, index, and scan costs. Controls tenant load and background work during failures.

Practice this question with an AI interviewer: https://sysround.com/practice/new?problem=time-series-database


---
SysRound (https://sysround.com) is an AI practice tool for system design interviews. It has a voice or typed AI interviewer and a shared whiteboard. At the end, you get feedback on each skill and a model answer. The AI feedback can be wrong.