What is a master-replica setup and why it matters?

Arpit Bhayani

entrepreneur, educator, and tinkerer

Master-Replica architecture is one the most common high-level architectural pattern prevalent in distributed systems. We can find it in use across databases, brokers, and custom-built storage engines. In this essay, we talk about everything we should know about the Master-Replica replication pattern.

A system that adheres to the Master-Replica replication architecture contains multiple nodes and each node, called Replica, holds an identical copy of the entire data. Thus if there are N nodes in the system, there will be N copies of the data.

Master-Replica Replication

Scaling Reads

With N nodes capable of serving the data, we easily scale up the reads by a factor of N. Hence, this pattern is commonly put in place to amplify and scale the reads that the system can handle.

Handling Writes

With N nodes that hold and own the data, the writes become tricky to handle. In the Master-Replica setup, the writes go to one of the pre-decided nodes that act as the Master. This Master node is responsible for taking up all the writes that happen in the system.

Master is not any special node; rather, it is just one of the Replicas with this added responsibility. Thus in the system of N nodes, 1 node is the Master that takes in all the writes, while the other N - 1 node caters to the read requests coming from the clients.

Write Propagation

Once the write operation is successful on the Master node, the changes are propagated to all the Replicas through Replication Log (Commit Log, Bin Log, etc.), letting the system eventually catch up.

The time elapsed between the write operation on the Master and the operation propagating to the Replica is called Replication Lag. This is one of the core metrics that is observed 100% of the time.

What happens when the Master goes down?

Since the Master node takes in all the write operations, it going down is a massive event. The write operation that happens when the Master is facing an outage results in an error.

When the system detects such an outage, it tries to auto-recover by promoting one active Replica as the new Master by running a Leader Election algorithm. All the healthy Replicas participate in this election and, through a consensus, decide the new Master.

Once the new Master is elected, the system starts accepting and processing the writes again.

Master-Replica in action

This is a widespread pattern that we can find across almost all the databases and distributed systems. Some of the most common examples are:

  • Relational databases like MySQL, PostgreSQL, Oracle, etc.
  • Non-relational databases like MongoDB, Redis, etc.
  • Distributed brokers like Kafka, etc.

Courses I teach

Alongside my daily work, I also teach some highly practical courses, with a no-fluff no-nonsense approach, that are designed to spark engineering curiosity and help you ace your career.

System Design Masterclass

A no-fluff masterclass that helps experienced engineers form the right intuition to design and implement highly scalable, fault-tolerant, extensible, and available systems.

Details →

System Design for Beginners

An in-depth and self-paced course for absolute beginners to become great at designing and implementing scalable, available, and extensible systems.

Details →

Redis Internals

A self-paced and hands-on course covering Redis internals - data structures, algorithms, and some core features by re-implementing them in Go.

Details →

Arpit Bhayani

Arpit's Newsletter

CS newsletter for the curious engineers

❤️ by 90000+ readers

If you like what you read subscribe you can always subscribe to my newsletter and get the post delivered straight to your inbox. I write essays on various engineering topics and share it through my weekly newsletter.

Writings and Learnings

Knowledge Base



Arpit's Newsletter read by 90000+ engineers

Weekly essays on real-world system design, distributed systems, or a deep dive into some super-clever algorithm.