In some scenarios, the most suitable way to resolve a conflict resolution may be dependent on the type of application being built.

👉 Most multi-leader replication tools allow you write custom conflict resolution logic using application code.

• This could be on executed on a write or a read ✍️ 📖
  • On write ✍️
    • As soon as the database detects a conflict in the log of replicated changes it will call a conflict handler
    • For example, Bucardo allows you to write snippets of Perl for this purpose
      • This handler typically cannot prompt a user
      • It runs as a background process and it must execute quickly
  • On read 📖
    • When a conflict is detected all the conflicting writes are stored
    • The next time data is read, these multiple versions of the data are returned to the application
    • The application may prompt the user or automatically resolve the conflict and write the result back to the database
    • For example: CouchDB works this way!

✋ To note, that conflict resolution is only applied on the individual row or document not for an entire transaction…

🤔 Meaning, if you have a transaction that makes several different writes, each write will need to be handled separately for the purpose of conflict resolution.

To be continued…

The final post will be covering the powerful capability of automatic conflict resolution and reasons why you may consider this approach, as writing custom conflict handlers can be error prone!

For more reading on conflict resolution:

• Avoiding Conflicts
• Converging Conflicts