A replication strategy where a one database handles all writes (the leader), and copies the data to one or more read-only databases (the followers).
This is a common way to make databases faster and safer. Instead of reading and writing from one place, we read from many (followers) but write in just one (leader). This helps the system handle more users and keeps data mostly consistent.
Use this when you have lots of users reading data (but fewer writing), and you want to scale without losing control over data changes.
You need to know
Only the leader can write – All updates go to the leader; followers just copy what the leader has.
Sync vs async replication – In sync, followers confirm before a write is "done" (slower but safer). In async, the leader doesn’t wait (faster but riskier).
If the leader fails, you need a plan – A follower can become the new leader, but your system must handle that switch quickly and correctly.
Consensus algorithms help pick a new leader – When the leader fails, algorithms like Raft or Paxos help the system agree on which follower should take over, so everything stays in sync.
Popular technologies
PostgreSQL – Popular relational database with built-in support for both sync and async leader-follower replication.
MySQL – Widely used in web apps; supports both basic leader-follower and more advanced failover mechanisms.
MongoDB – Offers automatic failover and replication; single primary node handles writes, others act as secondaries.
Like posts like this?
Every week, you'll get a new system design concept, broken down like this one.
Free subscribers also get a little bonus:
🎁 The System Design Interview Preparation Cheat Sheet
If you're into visuals, paid subscribers unlock:
→ My Excalidraw system design template – so you have somewhere to start
→ My Excalidraw component library – used in the diagram of this issue
No pressure though. Your support helps me keep writing, and I appreciate it more than you know ❤️