Choose the database from three workload signals
Label the workload, pick a data model, then name a product. Never start from the product.
Original Database Choices for System Design cheatsheet (LinkedIn) by Puneet Patwari
The idea
When a design needs storage, answer three questions before naming any database: what kind of workload is it (transactional, analytics, or search and logs), what is the traffic shape (read heavy, write heavy, balanced, spiky, hot keys), and how correct must it be (strong consistency or eventual is fine).
Those answers pick a data model first, and only then a technology. Going model-first keeps the answer about access patterns instead of brand names, and makes it easy to swap the product when the interviewer pushes.
Need → model → example tech
| If the need is… | Model | Examples |
|---|---|---|
| Money, joins, transactions | Relational | Postgres, MySQL; YugabyteDB or TiDB for multi-region |
| Flexible JSON, changing schema | Document | MongoDB, Couchbase |
| Fast ID lookups, hot keys | Key-value | Redis, Memcached |
| Very high write volume at scale | Wide column | Cassandra, HBase |
| Dashboards over history | Columnar | ClickHouse |
| Metrics over time | Time series | Timescale, InfluxDB, Prometheus |
| Text search, ranking, logs | Search | Elasticsearch, OpenSearch |
Need ultra-low latency on top of any of these? Add a cache in front rather than changing the primary store.
Four trade-off prompts
- What are the top queries?
- What correctness is actually required?
- Where are the hotspots?
- What breaks first at 10x?
Say it like this
- Before picking a store: this is OLTP, read heavy with a few hot keys, and balances need strong consistency. That points to a relational primary with a key-value cache in front.
- The events table is write heavy and append only, and we only read it in aggregate, so I'd keep it out of Postgres and use a columnar or time-series store for it.
Bring it up when they ask
- Which database would you use here, and why?
- Why not just use Postgres for everything?
- SQL or NoSQL?
- What happens to this data layer at 10x traffic?
Where it fits
- LaunchDarkly
- Flag configs are small, read heavy and need fast propagation (key-value plus streaming). Evaluation events and experiment metrics are write heavy and analytical (columnar or time series).
- iii
- Workflow state needs strong consistency per run (relational), while run logs and traces are append heavy and search shaped.