Primary-Replica Architecture
The single-writer topology used by most relational databases — how reads scale, how failover works, and the failure modes that come with it.
One node accepts writes. Others replicate from it and serve reads. This is the topology behind PostgreSQL, MySQL, MongoDB replica sets, Redis replication and most managed database services.
Why it dominates
The single writer removes an entire class of problems. There is exactly one authority for the current value of a row, so there are no write conflicts, no reconciliation rules, and no last-write-wins surprises. Almost everything you know about transactions on a single machine keeps working.
The cost is equally clear: write capacity is bounded by one node, and the loss of that node requires promoting a replacement.
Read scaling and its limit
Replicas scale read throughput, with three caveats worth stating explicitly.
- Every replica applies every write. Ten replicas do ten times the write work in total. If the workload is write-heavy, replicas do not reduce load — they multiply I/O across the fleet.
- Replica reads are stale. How stale depends on lag, which varies with load. Any read that must observe a just-completed write has to go to the primary or wait for the replica to catch up. See Consistency Models.
- Long queries on replicas can conflict with apply. In PostgreSQL, a long-running query on a
standby either delays WAL apply (
max_standby_streaming_delay) or is cancelled with a conflict error. Reporting queries and low replication lag are in direct tension.
Failover
Failover is the part teams under-rehearse. It has three requirements, and skipping any one turns a node failure into an outage or data loss:
- Detection. Something must decide the primary is gone. A single observer cannot distinguish a dead primary from a network partition, which is why cluster managers (Patroni, Orchestrator, Redis Sentinel, MongoDB's own election protocol) require a quorum of observers.
- Promotion. One replica becomes the new primary. If replication was asynchronous, whatever the old primary had not shipped is lost.
- Redirection. Clients must find the new primary — via a virtual IP, a proxy such as HAProxy or PgBouncer, a DNS change, or driver-level topology discovery. This step causes more incidents than the promotion itself.
Operational requirements
- Monitor replication lag with an alert threshold derived from your tolerance for stale reads, not from a round number.
- Rehearse failover on a schedule, in production, during working hours. A procedure that has never been executed is a hypothesis.
- Keep replicas on the same major version and comparable hardware. A weaker replica becomes a weaker primary at the worst possible moment.
- Confirm that a promoted replica is immediately protected: it needs its own replica and its own WAL archiving, or you have failed over into a single point of failure.