Tonight's interview move is choosing the right database shape before the diagram gets fancy. Most weak answers say "use SQL" or "use NoSQL" too early. Strong answers ask what the product reads, what it writes, how fresh the read must be, and which request will melt first.
The invariant
Replication copies data to scale reads and survive failures; sharding splits data to scale writes and size; indexes buy fast reads at write cost. Choose per access pattern.
An access pattern is one real product question: "get one user's orders," "append one chat message," "show the last 50 posts," "transfer money." The database choice follows that question. Do not start with a brand name; start with the request.
The script
Use the same seven-step system-design script every time. Here it is applied to database choices.
Requirements: decide which reads must be fresh, which writes must be all-or-nothing, and whether the data is relational, document-like, or key-value.
Estimate scale: write down read QPS, write QPS, row size, total data size, and growth. Reads, writes, and size fail in different ways.
API: name the endpoints because they reveal access patterns: GET /users/{id}, POST /orders, GET /orders?user_id=....
Data model: choose tables or documents around the transaction boundary. If money, inventory, or ownership can be half-wrong, prefer an ACID transaction boundary (PostgreSQL docs: transactions).
High-level boxes: draw app servers, a routing layer, primary data stores, read replicas, shard boundaries, and the indexes that serve the common lookups.
Deep-dive the bottleneck: if reads hurt, replicate or index; if writes or data size hurt, shard; if correctness hurts, shrink the transaction to the smallest safe boundary.
Failure modes: call out replica lag, hot shards, missing indexes, cross-shard transactions, backups, schema migrations, and what happens when the primary dies.
The architecture diagram
This is the picture to redraw from memory. Notice that replication, sharding, and indexes answer different pains.
The bottleneck deep-dive
In interviews, do not say "just shard it" as the first move. Name the bottleneck, then choose one of these three moves.
Indexes: use when the data fits, writes are acceptable, and a common lookup is scanning too much. An index is a second lookup structure; it speeds reads but must be maintained on writes (PostgreSQL docs: indexes).
Replication: use when reads dominate or you need a standby copy. Reads can move to replicas, but async replicas can lag behind the primary (Amazon RDS docs: read replicas).
Sharding: use when one machine cannot handle write load or data size. A good shard key makes the common request hit one shard; a bad key creates hotspots or scatter/gather queries (MongoDB docs: sharding).
SQL versus NoSQL is the next layer, not the first layer. Prefer SQL when relationships, joins, and transactions are central. Prefer a key-value or document store when the access pattern is simple, high-volume, and usually reads or writes one aggregate by key. Either way, the invariant stays the same: copy for reads, split for writes and size, index for lookup speed.
Numbers that matter
Rule of thumb
What it tells you
Source
3 replicas tolerate 1 failure in quorum systems
Replication helps survival, but more replicas can add write coordination cost.
1. Read traffic is overwhelming, writes are steady. What is the first database move?
Replication is the clean first move when reads dominate and freshness rules allow it. Sharding is for write load or size; deleting indexes usually makes reads worse.
2. A lookup is slow: GET /orders?user_id=7 scans orders. What should you try before sharding?
The access pattern is a lookup by user_id. If the table is scanning, an index on that lookup key is the direct fix before adding distributed complexity.
3. A system shards orders by created_at. Today's shard is melting. What went wrong?
A monotonically increasing shard key sends the newest writes to the same place. The system is sharded, but the write load is not spread.
4. Which request is safest to serve from an async read replica?
Analytics from yesterday can usually tolerate slight staleness. Money, checkout, and password changes need fresh reads and careful transactional behavior.
Your move (tonight)
Redraw the architecture diagram from memory on paper. Then explain the design out loud in 5 minutes as if to an interviewer: requirements, scale, API, data model, boxes, bottleneck, failure modes. No LeetCode tonight for this lesson.
One primary source
After your redraw, read AWS — Choosing an AWS database service as the compare step. Focus on how each database type is tied to an access pattern, not to hype.