Scalable Human Blog

One of the largest problems with multi-leader replication is handling conflicts. This is why conflict resolution is required.

🤔 How can a write conflict occur?

For instance, lets considers a wiki page being edited simultaneously between two users. 👨‍💼👨‍💼

❌ A scenario can occur when both users are editing the same text, and the changes are successfully applied to the leaders, however if if these are asynchronously applied… a conflict could occur.

🥴 To note, this problem does not occur in a single leader database.

⚔️ Synchronous vs asynchronous conflict detection

In a single leader database

• The second writer will either be blocked and have to wait for the first write to complete ✅⛔️
• Or… it will abort the second transaction, forcing the user to retry the write ✅❌

In a multi-leader setup

• Both writes are successful ✅✅
• And conflicts are only detected asynchronously at a later point in time
  • Although that time maybe too late… for the user to restore the conflict
• 🤔 You could make the conflict detection synchronous?
  • Wait for the write to replicate to all the replicas, telling the user that the write was successful
  • However, by doing this you will lose the main advantage of multi-leader replication…
    • 👉 Allowing each replica to accept writes independently

✋ To note, if you want synchronous conflict detection you may as well use single leader replication configuration.

🏃💥 Conflict avoidance

A clever person solves a problem. A wise person avoids it.

Albert Einstein

The simplest strategy to handle conflicts is to avoid them…

• The application can ensure that all records can go through the same leader and conflicts cannot occur!
• Since many implementations of multi-leader replication, these have been handled poorly to resolve conflicts

👍 Avoiding conflicts is a frequently recommended approach.👍

Considering conflict avoidance?

✅ In an application where users can edit there own data, you can ensure that there requests are routed to the same data centre, and use the leader in that data centre for reading and writing.

🤔 Different users may have different “home” data centres…

• Perhaps picked on geographical proximity to the user 📍
• But as from any users point of view this would appear as a single leader configuration set up

However, you may want to change the designated leader for a record…

• 💥 Maybe one data centre has failed?
  • And you may need to reroute data traffic to another data centre…
• Or perhaps a user has moved to a different location, and now is closer to another data centre?
  • In this situation conflict avoidance breaks down! 😨
  • And now you will have to deal with different concurrent writes on different leaders

To be continued…

There are even more solutions to handling conflict resolution, this will be covered in the next upcoming blog posts:

• Converging towards a consistent state
• Custom conflict resolution logic
• Automatic conflict resolution

📚 Further Reading & Related Topics

If you’re exploring conflict resolution and consistency in distributed data-intensive systems, you’ll also find value in these related posts:

• The Five Design Principles (SOLID) – Learn about the foundational principles that help structure clear, maintainable software, directly supporting consistency in complex systems.

• Designing Data-Intensive Systems: Version Vector Algorithm Explained – Deepen your understanding of algorithms used to track changes and resolve conflicts effectively across distributed nodes.