Master-replica architecture in Redis - Step-by-Step Execution

Concept Flow - Master-replica architecture

Client writes to Master

↓

Master stores data

↓

Master sends updates

↓

Replica receives updates

↓

Replica stores data copy

↓

Client reads from Replica or Master

Data is written to the master, which stores it and sends updates to replicas. Replicas keep copies and serve read requests.

Execution Sample

Redis

SET key1 value1
GET key1
# Master stores 'key1' with 'value1'
# Replica receives update
# Client reads 'key1' from replica

Shows how a write to master is replicated and then read from a replica.

Execution Table

Step	Action	Master State	Replica State	Client Request	Response
1	Client sends SET key1 value1 to Master	empty	empty	SET key1 value1	OK
2	Master stores key1=value1	key1=value1	empty	none	none
3	Master sends update to Replica	key1=value1	receiving update	none	none
4	Replica stores key1=value1	key1=value1	key1=value1	none	none
5	Client sends GET key1 to Replica	key1=value1	key1=value1	GET key1	value1
6	Client reads value1 from Replica	key1=value1	key1=value1	none	value1
7	Client sends GET key1 to Master	key1=value1	key1=value1	GET key1	value1
8	Client reads value1 from Master	key1=value1	key1=value1	none	value1
9	No more requests	key1=value1	key1=value1	none	none

💡 Execution stops after client reads value from master and replica; no more requests.

Variable Tracker

Variable	Start	After Step 1	After Step 4	After Step 6	Final
Master Data	empty	key1=value1	key1=value1	key1=value1	key1=value1
Replica Data	empty	empty	key1=value1	key1=value1	key1=value1
Client Request	none	SET key1 value1	none	GET key1	none
Client Response	none	OK	none	value1	none

Key Moments - 2 Insights

Why does the replica have 'empty' data after the client writes to the master?

Because the replica only updates after receiving the master's update (see Step 3 and 4 in execution_table). It does not store data immediately when the client writes to master.

Can the client read the updated data from the replica immediately after writing to the master?

No, the client must wait until the replica receives and stores the update from the master (Step 5 and 6). Before that, the replica has old or empty data.

Visual Quiz - 3 Questions

Look at the execution_table, what is the state of the replica after Step 2?

A empty

B key1=value1

C receiving update

D unknown

💡 Hint

Check the 'Replica State' column at Step 2 in execution_table.

At which step does the replica store the updated key1=value1?

A Step 3

B Step 4

C Step 5

D Step 6

💡 Hint

Look for when 'Replica stores key1=value1' in the Action column.

If the client reads from the master at Step 7, what response will it get?

A empty

B error

C value1

D OK

💡 Hint

Check the Response column at Step 7 in execution_table.

Concept Snapshot

Master-replica architecture:
- Client writes go to master only.
- Master stores data and sends updates to replicas.
- Replicas store copies and serve reads.
- Replication is asynchronous; replicas lag slightly.
- Reads can be load-balanced between master and replicas.

Full Transcript

In master-replica architecture, clients send write commands to the master server. The master stores the data and then sends updates to its replicas. Replicas receive these updates and store copies of the data. Clients can read data from either the master or replicas. This setup helps distribute read load and provides data redundancy. The replication is asynchronous, so replicas may lag behind the master briefly after writes. The execution table shows step-by-step how a write to the master propagates to replicas and how clients read data from both. Variables track the data state on master and replicas after each step. Key moments clarify common confusions about when replicas update and when clients can read fresh data from them. The visual quiz tests understanding of these steps and states.