How to choose a database by access pattern — not by hype.
What should you know before choosing SQL, NoSQL, graph, or search?
Write the primary read query and primary write operation before naming any database.
Database choice returns in URL mapping, messages, feeds, counters, videos, and notifications.
It's the most common follow-up in any system design interview, and the place where candidates most often reach for a brand name before they've stated the workload. The interviewer hears "Cassandra" and silently asks: okay, but why?
The clean way to think about databases is to flip the question. Don't start by asking which database. Start by asking what question does this system ask most often? — and let the answer pick the storage shape.
Once you internalize that sentence, the four shapes stop being trivia and start being decisions you can derive from the workload. Before naming any database, ask:
In real systems, you may use more than one store. But in interviews, start with the primary source of truth. Add stores only when scale or query shape forces the move.
The strong version ties the database to access pattern, consistency needs, and evolution path. That's what gets the head-nod.
Database choice starts with SQL versus NoSQL.
Database choice starts with access pattern, consistency need, relationships, and growth shape.
State the query shape first: lookup by key, relationship query, append-and-scan, or search.
| Database shape | Good when | Weak when | Interview line |
|---|---|---|---|
| Relational Default | Data is structured, related, and needs transactional correctness. | You're forcing massive simple key lookups or huge write-heavy partitions into a shape that doesn't fit. | I'd start relational because correctness across related records matters more here than maximal write scale. |
| Key-value | Reads are mostly by one key and the value behind it is simple to fetch. | You need rich querying, joins, or many ad hoc access patterns. | The main operation is lookup by key, so a key-value model keeps the hot path simple. |
| Document | Each entity is a flexible object and the app reads or writes the full object. | You need strong relational joins or normalized updates across many entities. | A document model fits because the record naturally travels as one object with flexible fields. |
| Wide-column | Data is very large, partitioned, and often write-heavy or time-ordered. | The system is small or the query pattern is relational and correctness-heavy. | I'd reach for wide-column only when partition scale and write throughput dominate. |
Do not jump straight from reading to a full answer. First see the shape, then complete part of it, then answer alone.
I would say: "For orders and payments, correctness and relationships matter, so I would start with a relational model."
For the store prompt, name one table-like relationship and one lookup that must be fast.
Pick a database only after writing the two most important queries.
Before moving on, turn recognition into production. Close the model answer, answer from memory, then retry one small slice.
Say the chapter's core idea without looking. Then name one related idea from an earlier chapter.
Change one constraint in the practice prompt and answer again in half the time.
Use the rubric to pick one dimension below 3, then retry only that dimension.
Workload first; product name last (or never).
Ledger · Locker · Folder · Warehouse aisle. The metaphor anchors the recall.
Caches, indexes, and analytics stores are extra — keep them off the first pass.