14.9 When would you have more than one leader?

Other shapes

At the bank: A bank with offices on three continents lets each regional office issue notices for local customers, instead of phoning one head office overseas for everything. Fast locally, but sometimes two offices change the same rule differently on the same day.

In the system: In multi-leader replication, several nodes accept writes and replicate them to each other.

Where it makes sense:

• Multiple regions: each region has a leader so users write with low latency, and regions keep working if the link between them breaks.
• Offline clients: a phone's calendar or notes app is effectively a leader that syncs later.
• Collaborative editing: every user's copy accepts edits that are merged.

The big problem is write conflicts: two leaders change the same data at the same time. Ways to resolve them:

• Last write wins (LWW): keep the one with the latest timestamp. Simple, but it silently throws away the other write, and clocks differ between machines (Chapter 10, section 10.7).
• Merge: combine the values (add both items to the cart, keep both edits).
• Ask the user, as file-sync tools do with "conflicted copy" files.
• CRDTs (conflict-free replicated data types): data structures designed so concurrent changes always merge to the same result, used by some collaborative editors and databases.

Avoid it if you can. Many teams route each user's writes to one home region (so each piece of data has one leader) and get most of the benefit without conflicts.

Memory code: "Many offices, many pens, and someone must settle the arguments."

---