Imagine a classroom where one teacher (master) writes notes on the board and multiple students (slaves) copy the notes. If the teacher leaves, one of the best students is chosen to take over and continue teaching. This ensures note-taking (data replication) continues smoothly without loss.
This mirrors how master-slave systems work: one central entity handles updates, and others copy the updates. If the central entity fails, one of the followers is promoted to take over.
Master-Slave architecture (also called Primary-Replica or Leader-Follower) is a distributed system pattern where:
- The master node (leader/primary) handles all write operations and pushes updates to the replicas.
- The slave nodes (followers/replicas) are read-only and synchronize their data from the master.
- If the master node fails, a leader election is triggered to promote one of the slaves to become the new master.
This design supports read scalability, fault tolerance, and data redundancy in distributed systems.
Layman View: The node with the highest ID or rank takes over if the leader is missing. Nodes with lower rank notify higher ones and wait for a response. If none respond, the initiator becomes the leader.
Technical View:
- Each node knows all other node IDs.
- If a node suspects the leader is down, it sends election messages to higher-ID nodes.
- If no higher-ID node responds, it declares itself the new leader.
- Otherwise, it waits for the leader declaration from a higher node.
Layman View: Like a democratic vote. All nodes vote, and a majority decision elects the new leader.
Technical View:
- Nodes start in a follower state.
- If no heartbeat is received, a node becomes a candidate and requests votes.
- If it receives a majority, it becomes the leader.
- Leader sends regular heartbeats to maintain authority.
| Type | Description |
|---|---|
| Static Master-Slave | Master is fixed, changes require manual intervention. |
| Dynamic with Election | Master is automatically chosen based on priority or votes. |
| Synchronous Replication | Writes are acknowledged only after all replicas confirm replication. |
| Asynchronous Replication | Master acknowledges writes immediately; replicas catch up later. |
| Node Role | Responsibility |
|---|---|
| Master | Processes all write requests, coordinates replication, manages data integrity. |
| Slave | Processes read requests, continuously replicates data from master. |
- Reduces load on a single node by distributing reads.
- Provides high availability by failing over to replicas.
- Improves fault tolerance and data reliability.
| System | Role of Master-Slave Architecture |
|---|---|
| MySQL/PostgreSQL | Master-slave replication for read scaling and failover. |
| Kafka | Partition leaders act as masters; followers replicate the partition. |
| MongoDB | Replica sets use a primary (master) with secondaries (slaves). |
| Redis | Redis Sentinel enables automatic failover in a master-slave cluster. |
- Heartbeat detection monitors the master.
- On failure, election starts using predefined logic (Raft, Bully, etc.).
- Once a slave is promoted, others adjust roles and resume replication.
- Consistency trade-offs between sync and async replication.
- Split-brain scenarios must be managed using quorum-based systems like Zookeeper or etcd.
- Lag monitoring is critical to ensure slaves are up-to-date.
Here is an extended section covering Master-Slave (Leader-Follower) architecture usage in Kubernetes, Apache Pulsar, and Apache Flink, following documentation style:
Architecture Usage: Kubernetes uses a leader-election mechanism primarily within its control plane components, especially among kube-controller-manager instances.
| Component | Role of Leader/Follower |
|---|---|
kube-controller-manager |
Multiple replicas run, but only one is active (leader) at a time. |
etcd |
Backend key-value store using Raft for leader election and consistency. |
Election Mechanism:
- Kubernetes uses a lease-based election via API server annotations (
configmapsorendpoints) or etcd. - Only the elected controller-manager performs operations like node management, deployment rollouts, etc.
etcduses the Raft consensus algorithm to elect a leader for consistent data access across cluster members.
Purpose Solved:
- Prevents split-brain in control logic.
- Ensures only one instance manages critical cluster state updates.
Architecture Usage: Pulsar uses a multi-layered architecture with leader-follower patterns in its components:
| Component | Role of Leader/Follower |
|---|---|
| BookKeeper | Handles storage; uses Bookie nodes with optional leader logic. |
| ZooKeeper | Coordinates Pulsar clusters, manages leader election. |
| Brokers | Stateless, but ZooKeeper assigns topic ownership to brokers (leader per topic). |
Election Mechanism:
- ZooKeeper elects leaders among brokers to assign partitions and topics.
- BookKeeper doesn’t strictly use master-slave, but data is written to a quorum of bookies and read from a subset.
- Segment Ownership behaves like partition-level leadership.
Purpose Solved:
- Ensures high availability of topic ownership.
- Supports automatic rebalancing and failover of topic assignment.
Architecture Usage: Flink’s architecture includes a JobManager (master) and TaskManagers (slaves).
| Component | Role |
|---|---|
| JobManager | Acts as master, handles scheduling, checkpointing, coordination. |
| TaskManager | Executes tasks assigned by JobManager, acts like slaves. |
High Availability:
- Multiple JobManagers can run in HA mode High Availability mode.
- ZooKeeper (or Kubernetes API) coordinates leader election.
- Only one JobManager is active at a time; others are passive standby.
Election Mechanism:
- JobManager leader is elected via ZooKeeper.
- On failure, a standby JobManager is promoted.
Purpose Solved:
- Prevents single point of failure for job orchestration.
- Ensures continuity in long-running data pipelines or streaming jobs.
| System | Uses Master-Slave / Leader-Follower? | Election Type | Purpose Solved |
|---|---|---|---|
| Kubernetes | Yes (control plane components) | Lease/ZooKeeper/etcd | Ensures control-plane consistency |
| Apache Pulsar | Yes (Brokers, BookKeeper, ZooKeeper) | ZooKeeper | Manages topic ownership & availability |
| Apache Flink | Yes (JobManagers & TaskManagers) | ZooKeeper/K8s API | Ensures failover for job scheduling |
Why is only one broker (leader) writing per partition, if the topic is spread across multiple brokers?
-
Topic ≠ Partition ≠ Broker
- A topic is a logical name.
- A topic is divided into partitions.
- Each partition has a leader broker and zero or more follower replicas.
- Kafka assigns partitions to brokers, and those brokers host the partition leaders or followers.
-
Each partition has:
- 1 leader broker: Handles all reads and writes.
- 0 or more followers: Replicate data from the leader.
- The followers are passive; they pull data from the leader and keep in sync.
- They are used for replication and fault-tolerance, not for writing directly.
| Setting | What happens? |
|---|---|
acks=0 |
Producer doesn’t wait for any response — fastest, but risky (fire-and-forget). |
acks=1 |
Producer waits for leader only to ack the write. If leader crashes before followers sync → possible data loss. |
acks=all |
Producer waits until all in-sync replicas (leader + followers that are caught up) confirm they got the message. Safest, but slower. |
Suppose:
-
Topic
my-topichas 3 partitions:P0,P1,P2. -
Cluster has 3 brokers:
B1,B2,B3. -
Partition assignment:
P0: Leader onB1, follower onB2P1: Leader onB2, follower onB3P2: Leader onB3, follower onB1
- Producer sends message for
P1→ it goes to leader broker B2. - Followers (e.g., B3) replicate the data from B2.
- Only one broker per partition is the leader — and only that broker gets writes.
This design:
- Prevents write conflicts or split-brain.
- Makes Kafka linearly scalable: each partition is append-only, ordered, and handled by one leader.
- Allows efficient replication and fault recovery (leader election if one goes down).
-
Topics are spread across partitions → each partition has one leader.
-
Only the leader broker of each partition accepts writes.
-
ackscontrols how much replication confirmation the producer waits for:0: none1: just the leaderall: leader + all in-sync replicas (followers)
- Breaking down by comparing Kafka, databases (like MySQL, PostgreSQL, MongoDB), and other tools (like Redis, Elasticsearch) in terms of replication roles and how failover works.
| Terminology | Meaning |
|---|---|
| Leader-Follower | Leader handles writes (and maybe reads), followers replicate from it. |
| Master-Slave | Older term (now discouraged). Same as leader-follower. |
| Primary-Secondary | Same concept; primary does writes, secondaries replicate. |
| Active-Passive | One node is active (primary), others are standby (for failover only). |
| Active-Active | All nodes are active — typically harder to guarantee consistency. |
| Tool/Tech | Replication Type | Write Target | Reads from Secondary? | Auto Failover? | Notes |
|---|---|---|---|---|---|
| Kafka | Leader-Follower (per partition) | Leader partition | No (consumers read from leader) | ✅ Yes, fast | Highly scalable via partitioning |
| MySQL | Primary-Secondary (async/sync) | Primary | ✅ Yes | ❌ Manual or with tools like MHA | Traditional RDBMS setup |
| PostgreSQL | Primary-Replica (WAL shipping) | Primary | ✅ Yes | ❌ Needs Patroni, etc. | Strong consistency with WAL |
| MongoDB | Primary-Secondary (Replica Set) | Primary | ✅ Yes (configurable) | ✅ Yes (via election) | Built-in replica set with voting |
| Redis (Cluster) | Master-Replica | Master | ❌ Writes only to master | ✅ Yes | Fast, but needs Sentinel or Redis Cluster |
| Elasticsearch | Primary-Replica (Shard-based) | Primary shard | ✅ Yes | ✅ Yes | Distributed search engine |
| Cassandra | Peer-to-peer (no leader) | All nodes equal | ✅ Yes | ✅ Yes | Eventual consistency, no leader |
-
Kafka uses leader-follower per partition:
- Highly parallelized.
- Leader handles all writes; followers are backups.
- Consumers pull from leaders.
-
Databases like MySQL and Postgres use primary-secondary (or leader-follower):
- Primary handles writes.
- Secondary/replica can serve reads (read scaling).
- Failover is possible but usually needs orchestration.
-
MongoDB (replica sets):
- Built-in election.
- Clients auto-detect new primary.
- Can read from secondaries with consistency tradeoffs.
-
Redis (standalone vs cluster):
- Master-replica.
- Redis Sentinel or Redis Cluster handles failover.
- Simple but fast.
-
Cassandra:
- No master or leader. Every node is equal.
- Good for high availability and multi-region.
- More complex consistency model (tunable consistency).
| Generic Term | Kafka | MySQL/Postgres | MongoDB | Redis | Cassandra |
|---|---|---|---|---|---|
| Leader | Partition Leader | Primary | Primary (Replica Set) | Master | N/A |
| Follower | ISR Replica | Secondary | Secondary | Replica | N/A (All peers) |
| Failover Logic | Built-in | Manual/Tool | Built-in (Election) | Sentinel | Built-in, via gossip |
| Reads from replica | ❌ No | ✅ Yes | ✅ Yes | ❌ No (usually) | ✅ Yes |
- Leader-follower, master-slave, and primary-secondary mostly mean the same thing, just different naming conventions in different systems.
- Kafka is partitioned and distributed — each partition has its own leader (not global).
- In databases, the leader (primary) is often per-database, not per-table or partition.
- Failover and read scalability depend on how each system is designed.