Master-Slave Replication: Database Architecture Explained (2026)

What is Master-Slave Replication?

Your database is the one component in a system that you cannot simply clone and forget. Servers are stateless, so you can add twenty of them behind a load balancer. But data has to stay correct, and the moment you keep it on a single machine, that machine becomes both your bottleneck and your single point of failure. Master-slave replication is the first and most common answer to this problem, and it shows up in almost every system design interview.

The idea is simple: one database server, called the master (modern tools call it the primary), accepts all writes. One or more copies, called slaves or read replicas, receive every change from the master and serve read traffic. Writes go to one place; reads go everywhere.

The University Notice Board Analogy

Think of how a university publishes exam results. The registrar's office keeps the master record of every student's marks. Nobody except the registrar is allowed to change it. But thousands of students want to see the results, so the office prints copies and pins them on notice boards across every campus building.

• The registrar's file is the master: it is the only place a mark can be changed.
• The notice boards are the read replicas: students read from whichever board is closest.
• If a re-evaluation changes a student's mark, the registrar updates the master file first, then sends fresh copies to every board.

Notice something important: for a few hours after a correction, some notice boards still show the old mark. The system is not broken. It is just catching up. Hold on to that thought, because it is exactly what replication lag looks like in a database.

Why do reads dominate?

Master-slave replication works because of one observation about real applications: reads massively outnumber writes. Think about how you use Instagram. In one session you might scroll through two hundred posts, open fifty profiles, and read a hundred comments. That is hundreds of reads. How many writes did you make? Maybe one like and one comment.

Most consumer systems see read-to-write ratios of 10:1, 100:1, or even higher. A social feed, a product catalog, a news site, a video platform: all of them are read-heavy. So if reads are 95% of your traffic, the smartest first move is to scale reads, and that is precisely what read replicas do. You keep one machine for the 5% (writes) and add as many machines as you need for the 95% (reads).

This is a form of horizontal scaling applied to the database layer: instead of buying one giant database server, you add more ordinary ones. Each replica you add increases your read throughput almost linearly, because read traffic is spread across more machines.

How does master-slave replication work? (Step by step)

Let's walk through the full life of a single write, say a user updating their profile bio.

1. The write hits the master. The application sends UPDATE users SET bio = '...' WHERE id = 42 to the master database. The master is the only node allowed to accept this statement.
2. The master records the change in its log. Before or as it applies the change, the master appends it to a replication log (the binlog in MySQL, the WAL in PostgreSQL). This log is an ordered list of every change ever made.
3. The master acknowledges the write. In the default (asynchronous) setup, the master tells the application "done" as soon as its own copy is updated. It does not wait for the replicas.
4. Replicas pull the log and replay it. Each slave streams the replication log from the master and applies the same changes, in the same order, to its own copy of the data. After replay, the replica's data matches the master's.
5. Reads are served by replicas. When another user opens that profile, the application routes the SELECT to one of the read replicas, often through a load balancer or a database proxy. The master never sees this query.

The routing in step 5 is called a read/write split. It can be done in application code (two connection pools: one for writes, one for reads), by an ORM, or by a proxy that inspects each query. Either way, the contract is fixed: all writes to the master, reads to the replicas.

What is replication lag?

Here is the catch, and it is the part interviewers love to probe. Because the master acknowledges a write before the replicas have applied it, there is a window of time when the master has the new data and a replica still has the old data. That window is replication lag. It is usually milliseconds, but under heavy load it can stretch to seconds or worse.

This means a master-slave system is eventually consistent for reads that go to replicas: every replica will converge to the correct value, but not instantly. Just like the notice boards showing an old mark for a few hours, a replica can serve stale data for a short window.

The classic bug: read-your-own-writes

The most common symptom is a user who updates their profile picture, the page reloads, and the old picture shows up. What happened? The write went to the master, but the very next read went to a replica that had not caught up yet. The user thinks your app is broken.

Standard fixes you should be able to name:

• Read-your-own-writes routing: for a short period after a user writes, route that user's reads to the master.
• Sticky sessions or versioning: track the last write timestamp and only serve reads from replicas that have caught up past it.
• Synchronous replication: make the master wait for at least one replica to confirm before acknowledging the write. Safer, but every write gets slower. This is the classic consistency-versus-latency trade-off.

What happens when the master fails? (Failover)

Replication does not only scale reads; it also gives you a warm standby. If the master machine dies, you do not lose the data, because the replicas hold near-complete copies. The process of recovering is called failover:

1. Detect that the master is down (health checks, heartbeat timeouts).
2. Promote one replica, ideally the one most caught up on the log, to become the new master.
3. Repoint the application's write traffic and the other replicas to the new master.

Failover sounds clean on a whiteboard, but mention the sharp edges and you will stand out. First, any writes the old master had not yet replicated are lost in asynchronous setups. Second, if the old master was not actually dead, just slow, you can end up with two nodes both accepting writes. That situation is called split-brain, and it corrupts data. Real systems use consensus or fencing mechanisms to make sure exactly one master exists at a time. Tools like MySQL with Orchestrator, or PostgreSQL with Patroni, automate this promotion safely.

When should you move beyond master-slave?

Master-slave replication scales reads, availability, and backups. It does not scale writes. Every write still funnels through one machine, and every replica must replay every write. So when do you outgrow it?

• Write throughput hits the master's ceiling. If your workload is write-heavy (chat messages, telemetry, order events), adding replicas does nothing. You need sharding: splitting the data itself across multiple masters, each owning a slice. I cover how replication and sharding fit together in database design: replication, sharding, and consistency.
• Your data no longer fits one machine. Replication copies the full dataset to every node. If the dataset itself is too big, again, sharding is the answer, not more replicas.
• You need writes in multiple regions. Multi-master replication lets several nodes accept writes, which helps geo-distributed apps, but it introduces write conflicts (two masters update the same row) that must be resolved. Most teams avoid it unless they truly need it.

A good rule of thumb for interviews: start with a single master plus read replicas, and only reach for sharding or multi-master when you can point to a concrete write bottleneck. Jumping straight to the complex option is a red flag, not a flex.

Want to master this with video lessons and real case studies? This topic is covered in depth in my Udemy course System Design Fundamentals for Interviews — 5.5 hours, rated 4.8★, built from real interview questions.

How to talk about this in an interview

When the interviewer says "your database is becoming a bottleneck, what do you do?", here is a 30-second answer you can adapt:

"Most workloads are read-heavy, so my first step is master-slave replication: one primary takes all writes and streams its change log to read replicas, and the application does a read/write split. That scales read throughput horizontally and gives me a warm standby for failover. The trade-off is replication lag: replicas are eventually consistent, so for flows like read-your-own-writes I'd route those reads to the primary. If writes themselves become the bottleneck, replication won't help, and that's when I'd shard the data across multiple primaries."

Then be ready for the three follow-ups that almost always come next:

• "What about the lag?" Explain asynchronous versus synchronous replication and read-your-own-writes routing.
• "What if the master dies?" Walk through failover, promotion, potential lost writes, and split-brain.
• "What if writes grow 10x?" Say sharding, and explain why more replicas would not help.

Answering in that order, pattern, trade-off, escalation path, shows the interviewer you understand the design and not just the vocabulary.

Key Takeaways

• Master-slave replication = one node (master/primary) takes all writes; replicas copy its change log and serve reads.
• It works because real systems are read-heavy; replicas scale read throughput almost linearly.
• Replication lag makes replica reads eventually consistent; handle read-your-own-writes explicitly.
• Failover promotes a replica to master when the master dies; watch out for lost writes and split-brain.
• Replication does not scale writes or dataset size; that is the job of sharding or multi-master setups.

Next Steps

You now have the core building blocks: scaling, load balancing, caching, and replication. Time to put them together. In the next tutorial we take a real interview question, design a social bookmarking service like del.icio.us, and walk through a full end-to-end system design: requirements, API, data model, and exactly where master-slave replication fits in the final architecture.