EP 6.3: Master-Slave Architecture

Source: Dev.to

Overview

In system design, the Master‑Slave (or Leader‑Follower) architecture is a fundamental pattern used to achieve scalability and high availability, especially in database systems. It models communication where one device or process (the Master) has unidirectional control over one or more other devices or processes (the Slaves).

MASTER → SLAVE

In a data‑driven application, this architecture separates write operations from read operations.

Core Concepts

• Source of Truth – The Master handles all write operations (INSERT, UPDATE, DELETE).
• Coordination – The Master records changes in a log.
• Propagation – The Master pushes changes to the Slaves so they stay in sync.
• Read‑Only – Slaves are generally restricted to read operations.
• Data Replication – Slaves continuously pull or receive updates from the Master.
• Scalability – You can add as many Slaves as needed to handle read traffic.

Replication Types

Synchronous Replication

• The Master waits for all Slaves to confirm they have written the data before acknowledging the write to the client.
• Pros: Zero data loss.
• Cons: Higher latency; the system is limited by the slowest Slave.

Asynchronous Replication

• The Master writes the data, immediately acknowledges the client, and then sends the data to Slaves in the background.

Semi‑Synchronous Replication

• The Master waits for at least one Slave to acknowledge the update before completing the write.

Why Use Master‑Slave Architecture?

Read Scalability

• Ideal for read‑heavy applications (e.g., social media platforms) where many reads occur per write. Multiple Slaves can share the load.

High Availability

• If a Slave fails, the system continues operating. If the Master fails, a Slave can be promoted to become the new Master.

Analytic Isolation

• Heavy analytical queries can run on a Slave without impacting the Master’s performance for live transactions.

Backups

• A Slave can be paused for a full database backup without affecting the Master’s live workload.

Eventual Consistency

• Due to replication lag, a read from a Slave may return stale data shortly after a write to the Master.

Write Bottleneck

• Only one Master handles writes, which can become a bottleneck for write‑intensive workloads (e.g., high‑frequency trading).

Failover Complexity

• Promoting a Slave to Master during a crash requires careful coordination (often handled by tools such as Sentinel or Zookeeper) to avoid data corruption or split‑brain scenarios.

Common Use Cases

• E‑commerce sites: Writes (e.g., profile updates) go to the Master; product browsing reads from multiple Slaves.
• Redis: Primary cache node acts as Master; Slaves provide high‑speed read access and ensure data durability.
• Hadoop Distributed File System (HDFS): The NameNode is the Master (metadata), while DataNodes are Slaves (actual data blocks).

Conclusion

Master‑Slave architecture separates write and read responsibilities, enabling scalability, high availability, and isolation of workloads. By understanding the trade‑offs of synchronous, asynchronous, and semi‑synchronous replication, you can choose the right configuration for your application’s consistency and performance requirements.