Leader-Follower Replication

The leader is the sole node authorized to accept and process write operations (inserts, updates, deletes). This eliminates write-write conflicts that arise in multi-leader systems, as all data modifications are serialized through a single point. Followers are restricted to serving read requests, providing a clear separation of concerns. This model simplifies application logic but introduces a potential single point of failure for writes, which is mitigated by leader election protocols.

Changes are propagated from the leader to followers via a replication log.

• Synchronous Replication: The leader waits for confirmation from one or more followers before acknowledging a write to the client. This guarantees strong consistency but increases write latency.
• Asynchronous Replication: The leader acknowledges the write immediately and propagates changes to followers in the background. This offers lower latency but risks data loss if the leader fails before replication completes, resulting in eventual consistency. The choice is a trade-off between durability and performance.

A primary benefit is horizontal read scalability. By directing read queries to follower nodes, the system distributes the read load, preventing the leader from becoming a bottleneck. This is ideal for workloads with a high read-to-write ratio, common in agentic systems where many agents may query shared memory concurrently. Load balancers can route read traffic across the follower pool, significantly increasing overall system throughput for query operations.

The system is designed to tolerate node failures. If a follower fails, read traffic is redirected to other available nodes. The critical process is leader failover: if the leader becomes unavailable, a consensus algorithm (like Raft or a similar protocol) is used to elect a new leader from the follower pool. The newly promoted follower applies any pending entries from the replication log to ensure it has the latest state before accepting writes, maintaining system availability.

In asynchronous setups, replication lag—the delay between a write on the leader and its application on a follower—is inevitable. This creates consistency models:

• Strong Consistency (Read-after-Write): Guaranteed by reading from the leader or synchronously updated followers.
• Eventual Consistency: Reading from an asynchronous follower may return stale data.
• Monotonic Reads: A client always sees a non-decreasing set of updates, often ensured by routing a client's reads to the same follower. Architects must choose the model based on application requirements.

Leader-Follower differs from other replication strategies:

• vs. Multi-Leader: Allows writes to multiple nodes, increasing write availability but introducing complex conflict resolution needs (e.g., using CRDTs).
• vs. Leaderless (Dynamo-style): Clients write to and read from multiple nodes; consistency is achieved via quorums and read repair. Leaderless offers higher write availability but more complex client logic. Leader-Follower provides a simpler, strongly consistent write path at the cost of write availability during leader failure.

A consistency model that guarantees any read operation returns the value of the most recent write operation, making the system appear as if it has a single, up-to-date copy of the data. In a leader-follower setup, this is typically enforced by having reads that require absolute freshness go through the leader or by using a quorum-based read from followers where the leader synchronously confirms the latest write.

• Key Mechanism: Linearizability or sequential consistency.
• Trade-off: Provides simplicity for developers but can increase latency and reduce availability during network partitions compared to eventual consistency.

A consensus algorithm for managing a replicated log, explicitly designed around the leader-follower model. It elects a single leader who manages all client requests and log replication to followers. It is more understandable than Paxos and is foundational for systems like etcd and Consul.

• Leader Election: Uses randomized timers to elect a new leader if the current one fails.
• Log Replication: The leader appends commands to its log and replicates them to a majority of followers before committing.
• Safety: Guarantees state machine replication; all servers execute the same commands in the same order.

A replication strategy where multiple nodes can accept write operations. This contrasts with single-leader (leader-follower) replication by allowing writes at any location, improving write availability and reducing latency for geographically distributed agents. It introduces the challenge of write conflicts that must be resolved.

• Use Case: Collaborative editing or multi-region databases where each region has a leader.
• Conflict Resolution: Requires strategies like last-write-wins (LWW), application-defined merge logic, or Conflict-Free Replicated Data Types (CRDTs).

A fundamental durability mechanism used by leader nodes in database and stateful stream processing systems. All modifications to data are first written sequentially to a persistent log before being applied to the main in-memory data structures (like a B-tree). This log is the source of truth for replicating changes to followers.

• Crash Recovery: After a failure, the system replays the WAL to reconstruct state.
• Replication Feed: The leader's WAL often serves as the replication stream sent to followers (e.g., PostgreSQL WAL shipping, Kafka log segments).

The minimum number of nodes in a distributed system that must participate in an operation for it to be considered valid. Used to enforce consistency in leader-follower systems despite node failures.

• Write Quorum (W): Number of nodes (including the leader) that must acknowledge a write. Often W = majority (N/2 + 1).
• Read Quorum (R): Number of nodes from which a read must gather responses. For strong consistency, R + W > N ensures the read contacts at least one node with the latest write.
• Trade-off: Configuring R and W allows tuning between consistency, availability, and latency.

A consistency model that guarantees if no new updates are made to a data item, all reads will eventually return the last updated value. It does not guarantee when this will happen. In a leader-follower system, followers may serve stale reads if they haven't yet received updates from the leader, making this a common model for read replicas optimized for scale.

• Use Case: Social media feeds, product catalog caches, and analytics queries where immediate precision is not critical.
• Mechanism: Updates are asynchronously propagated from the leader to followers via a replication log.