EP 6.3: Master-Slave Architecture

#architecture #database #systemdesign

In system design, the Master-Slave (or Leader-Follower) architecture is one of the most fundamental patterns used to achieve scalability and high availability, particularly in database systems. :)

Consider it like a leader asking its followers to do something and the followers comply with it.

At its core, it is a model of communication where one device or process (the Master) has unidirectional control over one or more other devices or processes (the Slaves).

MASTER -> SLAVE

1. HOW IT WORKS?

In a data-driven application, this architecture separates the writing of data from the reading of data.

The Master (The Leader)

Source of Truth: The Master handles all Write operations (INSERT, UPDATE, DELETE).
Coordination: Records these changes in a log.
Propagation: Resp. for pushing changes to Slaves so that they are i sync.

The Slaves (The Followers)

Read-Only: Generally restricted to Read operations.
Data Replication: They constantly pull or receive updates.
Scalability: Add as many slaves as per the traffic.

Basically, Master commands and the Slave Follows, like followers can be a lot, there can be a lot of slaves for one master.

2. Replication Methods

To understand the "in-depth" side, you have to look at how data actually moves from Master to Slave:

Synchronous Replication: The Master waits for all Slaves to confirm they have written the data before telling the user the "Write" was successful.

Pro: Zero data loss.
Con: High latency (the system is only as fast as its slowest Slave).

Asynchronous Replication: The Master writes the data, sends a success message to the user immediately, and then sends the data to Slaves in the background.
Pro: Very fast performance.
Con: If the Master crashes before the data hits the Slaves, that data might be lost (Replication Lag).
Semi-Synchronous: The Master waits for at least one Slave to acknowledge the update before finishing.

3. Why Use It? - Advs :)

Read Scalability: If your app is "read-heavy" (like Twitter, where millions read a tweet but only one person writes it), you can spin up 10 Slaves to handle the load.
High Availability: If a Slave dies, the system stays up. If the Master dies, one of the Slaves can be "promoted" to be the new Master.
Analytic Isolation: You can run heavy, slow analytical queries on a Slave without slowing down the Master that is busy handling live user transactions.
Backups: You can pause a Slave to take a full database backup without affecting the live performance of the Master.

4. The Challenges - Dis Advs :(

Eventual Consistency: Because of replication lag, a user might write data to the Master and immediately try to read it from a Slave, but see the "old" data because the update hasn't arrived yet.
Write Bottleneck: You can only have one Master for writes. If your app has massive write traffic (like a high-frequency trading bot), a single Master becomes a bottleneck.
Failover Complexity: Promoting a Slave to a Master during a crash requires complex logic (often handled by tools like Sentinel or Zookeeper) to ensure no data is corrupted or "Split-Brain" scenarios occur.

5. Real-World Examples

A. Relational Databases (MySQL/PostgreSQL)

A typical e-commerce site uses Master-Slave. When you update your profile (Write), it hits the Master. When you browse products (Read), the app queries one of the many Slaves.

B. Redis (Caching)

Redis uses this to ensure that if the primary cache node goes down, the data isn't lost from memory. Slaves provide high-speed read access to cached objects.

C. Distributed File Systems (HDFS)

In the Hadoop Distributed File System, the NameNode acts as the Master (holding the metadata/map of where files are), while DataNodes act as Slaves (storing the actual chunks of data).