shreyansh

Multi-Leader Replication

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