The Six Database Questions Every System Design Eventually Asks

Every database I have ever worked with eventually forced me to answer the same six questions. Postgres, DynamoDB, Cassandra, Spanner, Mongo, even the boring MySQL replica behind some internal admin tool. The vendor changes. The wire protocol changes. The pricing model changes. The questions do not.

Here they are, in the order they tend to show up.

1. How do writes happen? Synchronous to one node, then replicated? Quorum across many? Append-only log that compacts later? This decides your durability story and your write tail latency.
2. How are reads served? Off the leader, off a replica, off a cache, off a materialized view? Every read path you add is another piece of state you have to invalidate later.
3. What gets indexed? Every secondary index is a second write on every update. You pay for the read speedup in write amplification and storage, forever.
4. What needs transactions? Be specific. A single row update is not a transaction problem. A money transfer across two accounts is. Most systems need transactions in three or four narrow places and eventual consistency everywhere else.
5. How is data replicated? Leader-based, multi-leader, leaderless? What happens on conflict? Last writer wins is fine for a like counter and catastrophic for an inventory count.
6. How is data partitioned? By hash, by range, by tenant? This is the decision you will regret two years from now if you get it wrong, because repartitioning live data under load is one of the worst on-call experiences in distributed systems.

A concrete failure mode that taught me to take question six seriously: a payments system I worked on partitioned transactions by merchant_id. Fine at first. Then one merchant ran a viral promo and pushed 40% of all writes into a single partition. The hot partition lagged replication, then started rejecting writes, then took down the broader cluster because the coordinator was waiting on quorums that could not finish. The fix was not more hardware. The fix was a composite key, merchant_id plus a bucket suffix, which required a multi-month migration of a live ledger. If we had asked question six honestly on day one, we would have picked the composite key from the start.

That is the value of the six questions. They are not trivia. They are the load-bearing decisions. Get them right and the rest of the architecture, caches, queues, search indexes, fan-out workers, mostly arranges itself. Get them wrong and no amount of Kafka or Redis on top will save you.

Learn the six. Ask them out loud in every design review. The systems get clearer almost immediately.