Skip to main content

Database Architectures

Every lesson in this module has covered one piece of a database in isolation — transactions, schema choice, indexing, sharding, replication. A database architecture is what you get when those pieces are assembled into a complete topology: how many nodes, which ones accept writes, how they stay in sync, and what happens when one of them fails. This lesson is a capstone, walking through the standard topologies and where each piece from the rest of this module fits into them.

Single-leader: the default starting point​

The topology covered in Data Replication — one leader accepting writes, followers replicating from it and serving reads — is the architecture most systems start with, and for good reason: write ordering is unambiguous (there's only one place writes originate), and it's the simplest topology to reason about and operate. Its limits are exactly what the rest of this module exists to address: a single leader caps write throughput, and the whole dataset still has to fit within what one leader (and each full-copy follower) can hold — which is what eventually motivates Database Sharding.

System Design Lab

A production system that's both sharded and replicated — the common end state for a large system — is really this pattern repeated: each shard is its own independently-replicated single-leader group, so the system as a whole scales writes (via sharding) and survives node failure (via replication) at the same time.

Multi-leader and leaderless: giving up a single write path on purpose​

Single-leader replication assumes one write path is acceptable — but that assumption breaks down across distant geographic regions (every write crossing an ocean to reach one leader adds real latency) or when write availability has to survive a leader outage without waiting for a promotion. Two alternatives trade write-path simplicity for exactly those properties:

  • Multi-leader — more than one node accepts writes (often one leader per region), and leaders replicate to each other. This directly trades away single-leader's easy write ordering: if the same record is written differently at two leaders before they sync, that's a genuine conflict that needs an explicit resolution policy (last-write-wins, application-level merge logic).
  • Leaderless — any replica can accept a write; reads and writes use quorums (e.g. write to W replicas, read from R replicas, chosen so W + R > N guarantees overlap) to stay consistent enough without ever electing a leader at all. This is the Dynamo-style approach referenced in Consistent Hashing's Further Reading, and it favors write availability over the simplicity of single-leader ordering.

Both of these are concretely the CAP Theorem tradeoff showing up in a specific replication design — choosing to keep accepting writes during a partition (AP) instead of blocking until a single leader can confirm them (CP) — and both connect to Strong vs. Eventual Consistency, which covers the read-side consequence of this choice: a read right after a multi-leader or leaderless write might not reflect it yet everywhere.

Read/write splitting and polyglot persistence​

Two more architectural moves worth naming, since they show up constantly in real designs:

  • Separating the read and write paths — routing writes to a leader and reads to replicas (or, further, to a cache in front of them) is already implicit in leader-based replication, but it's worth stating as a deliberate architectural choice: it lets the read path and write path scale, and even fail, somewhat independently.
  • Polyglot persistence — using several different database types side by side within one system, each chosen for the access pattern it's actually serving (relational for transactional core data, a search index for the search bar, a key-value store for sessions), rather than forcing one database to be good at everything.

How a node failure actually gets handled​

None of these topologies survive a node dying by accident — they need an explicit mechanism, which is where this module connects back to Core Concepts and forward to Distributed Systems: a dead leader needs failover (an automated promotion of a follower), and correctly agreeing on which follower becomes the new leader without split-brain is a consensus problem in its own right. A full regional outage is the scenario Disaster Recovery covers.

Why this matters in an interview​

A strong system design answer doesn't stop at "we'll use a database" — it names the topology (single-leader, sharded, multi-leader), justifies it against the read/write pattern and geographic spread the prompt implies, and says explicitly what happens when a node in that topology dies. That's the point of this whole module: transactions, indexing, sharding, and replication aren't independent trivia, they're the parts that combine into one coherent, defensible database architecture.

Single-leader vs. leaderless replication: pros and cons​

Single-leader

  • Unambiguous write ordering — no conflicting writes to reconcile
  • Simpler to reason about, operate, and debug
  • Reads can be made strongly consistent by reading from the leader

Leaderless

  • Requires read/write quorums on every request, adding coordination overhead
  • No single, simple ordering of writes — conflict resolution is a first-class concern
  • Harder to reason about what a client will actually observe after a write

Further Reading​

Saved locally in your browser — visible in the sidebar as you go.