Database Replication

How it works

Replication keeps multiple copies of a database in sync so a single node failure doesn't take down reads or writes. Master-slave sends all writes through one master and fans reads out to read-only replicas; master-master lets writes land on either node, trading a single write bottleneck for conflict-resolution risk.

Mental models

• Master-slave: one master serves writes and replicates them to slaves that serve reads only — simple, but a single write bottleneck.
• Master-master: both nodes accept writes and sync with each other — no single write bottleneck, but conflicts are now your problem.
• If the master goes down in master-slave, the system can keep serving reads until a slave is promoted or a new master is provisioned.
• Replication lag is real: the more read replicas, the more there is to replicate, and reads can briefly see stale data.
• This is the same fail-over pattern as active-passive (master-slave) vs active-active (master-master) load balancing — same tradeoff, different layer.

Common pitfalls

• Losing the master before a write replicates means that write is gone — replication doesn't replace backups.
• Master-master either loosens consistency (violates strict ACID) or pays a latency tax to synchronize writes across nodes.
• Promoting a slave to master isn't automatic — someone, or some system, has to detect the failure and do it correctly, fast.