shreyansh

MultiLeader Replication - chaos

30-Second Glance

  • Any leader accepts writes locally (Europe need not round-trip to Africa/APAC) and async-propagates to other leaders and followers.
  • Leaders forward writes in circle, star, or all-to-all topologies; each needs loop-suppression via a "seen by" set in the replication log.
  • All-to-all scales worst: O(N²) connections, high bandwidth, quadratic management complexity.
  • Async multi-leader means temporary inconsistency and frequent concurrent-write conflicts needing LWW or custom resolution.
  • The note's verdict: great for latency, chaotic for consistency — conflicts get their own follow-up note.

Multi-Leader Replication

As an alpha sigma Male myself, not a big fan of having multiple leaders. Clearly, such a setup is destined to fail and has many problems with it, as you'll see in the following article.

Screenshots/0656ab5346cd976941b9423b67268769_MD5.jpeg
  • Anyone can write to any Leaders and they can write anything and we can read from followers to which the writes will be propagated asynchronously.
  • The guy in Europe doesn't have to write all the way to Africa or APAC.

Configurations where Leaders can pass their writes from one to another.

Topologies:

  1. Circle Topology:

Screenshots/5f4839e1a0e894927868a0f68adcc39c_MD5.jpeg

  1. Start topology

e49c8df8be0d76515b3bfa73376291a6_MD5.webp

  1. All to All Topology

d9b61db6d3fa1a2d238bb98b21316b83_MD5.webp

Disadvantages of All-to-All Topology

  1. Network Overhead:

    1. High network traffic due to each node needing to communicate with every other node.
    2. This can lead to significant bandwidth usage and increased latency, especially in large systems.

  2. Complexity:

    1. Managing a large number of connections becomes complex and error-prone.
    2. More sophisticated conflict resolution mechanisms are needed to handle concurrent writes and ensure data consistency.

  3. Scalability Issues:

    1. As the number of nodes increases, the number of connections grows quadratically (N*(N-1)/2).
    2. This limits the scalability of the system and can lead to performance bottlenecks.

  4. Conflict Resolution:

    1. Increased likelihood of conflicts due to simultaneous writes on different nodes.
    2. Requires robust conflict resolution strategies (e.g., Last Write Wins, custom resolution logic) which can be difficult to implement effectively.

  5. Data Consistency Challenges:

    1. Ensuring data consistency across all nodes is challenging due to the asynchronous nature of replication.
    2. Temporary inconsistencies can arise, making it difficult to provide strong consistency guarantees.

Modifying the Replication Log:

Before (in Replication Log) After (add this)
id: 5, key: Jordan, value: sexy Seen by: 1, 3, 5 --> (which replicas has seen this write? Don't want to duplicate!!)
To keep track of this write as it goes to a specific node, we can add that in our replication log that this write was seen by that specific DB node.
This will ensure that our systems are not sending the writes infinitely in all the directions if we know that this write has been seen by these many DB nodes.

Write Conflicts:

Screenshots/101df6a686a5b030a36730e12c38d945_MD5.jpeg
Screenshots/04235d4cdebff278c622dcd5e79d3634_MD5.jpeg

Trade-offs

Approach Pros Cons Use when
Circle topology Few connections per node, simple forwarding Slow propagation; one break stalls the ring Few datacenters in a ring
Star topology Central coordination, simple routing Center is a bottleneck and single point of failure Small hub-and-spoke deployments
All-to-all topology Fastest propagation, no single relay O(N²) connections, bandwidth burn, hardest conflict resolution Small clusters that need fast fan-out
Replication-log "seen by" tracking Stops infinite rebroadcast and duplicates Extra metadata per write Any multi-leader forwarding setup

Interview One-Liners

Q: What is multi-leader replication's headline benefit? A: Local writes at every region — a European client doesn't round-trip to Africa or APAC.

Q: Name the three leader-to-leader topologies. A: Circle, star, and all-to-all.

Q: Why does all-to-all scale poorly? A: Connections grow as N·(N−1)/2 with high bandwidth use, management complexity, and more concurrent-write conflicts.

Q: How does the note stop writes looping forever? A: By tagging each replication-log entry with a "seen by" replica set so nodes don't resend duplicates.

Q: Why are conflicts inherent here? A: Asynchronous replication lets two leaders accept simultaneous writes with no natural order, forcing LWW or custom resolution.

Q: When would you still pick multi-leader? A: Geo-distributed writes where local latency and write availability outweigh consistency pain.