Registrations for the November 2021 System Design Cohort are now open Enroll Today

Master-Replica Replication

Published on 7th Aug 2021

2 min read

Share this article on


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.

If my work adds value, consider supporting me


Buy Me A Coffee

Arpit's Newsletter

2000+ Subscribers

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 👇



Other articles that you might like

The RUM Conjecture

The RUM Conjecture

While designing any storage system the three main aspects we optimize for are Reads, Updates, and au...

31st May
Replication Formats

Replication Formats

When we are employing a Master-Replica pattern to improve availability, throughput, and fault-tolera...

15th Aug
Persistent Data Structures - An Introduction

Persistent Data Structures - An Introduction

Persistent Data Structures allow us to hold multiple versions of a data structure at any given insta...

7th Feb
Handling outages in a Master-Replica setup

Handling outages in a Master-Replica setup

This essay talks about the worse - nodes going down - impact, recovery, and real-world practices....

7th Sep