Designing DIA note 36 -- handling write conflicts

5.3.1.3 Collaborative editing

Real-time collaborative editing -- Etherpad, Google Docs

• local replica ==> the state of the doc in their app or browser
• async replication ==> to server and any other editing users

5.3.2 Handling Write Conflicts

biggest problem with multi-leader replication ==> write conflicts can occur

Figure 5-7. A write conflict caused by two leaders concurrently updating the same record.

5.3.2.1 sync vs. async conflict detection

5.3.2.2 conflict avoidance

• simplest strategy ==> avoid

If the app can ensure that all writes for a particular record go through the same leader, then conflicts cannot occur.

5.3.2.3 converging toward a consistent state

If each replica simply applied writes in the incoming order, the DB would end up in an inconsistent state ==> problem

To achieve convergent conflict resolution:

• give each write a unique ID (timestamp, random number, UUID, hash), pick the write with the highest ID as the winner (ex. timestamp, LWW = Last Write Wins)
  ==> popular but prone to data loss
• give each replica a unique ID, let writes originated from a higher-numbered replica always take precedence
  ==> imply data loss
• merge the values together somehow
• record the conflict, and let app code to resolve the conflict later (ex. by prompting the user)

5.3.2.4 custom conflict resolution logic

on write

• call the conflict handler as soon as the DB system detects a conflict -- this handler is a background process

on read

• store all the conflicting writes are stored when a conflict is detected, then the app may prompt the user or automatically resolve the conflict when the next time the data is read

5.3.2.5 What is a conflict?

Some conflicts are obvious, others can be more subtle to detect.

• obvious ==> 2 writes concurrently modified the same field
• not obvious ==> for meeting room booking, if 2 bookings are created for the same room at the same time, there can be a conflict if the 2 bookings are made on 2 leaders

Reference
Designing Data-Intensive Applications by Martin Kleppman