Reconciling divergent writes is a product decision

After a split brain or a lossy promotion there can be two versions of some records, each written by users who were told it worked. Something has to decide which survives, and the answer depends on what the record means.

Databases offer rules. Last writer wins keeps the version with the later timestamp and silently drops the other; because clocks drift, that order is effectively arbitrary. DynamoDB global tables use it for concurrent updates in two regions. Ian Gorton concludes it is safe only when every write goes to a new key and nothing is updated in place. Some data merges cleanly: CRDTs such as counters and sets converge on every replica. Otherwise Riak, for one, keeps both versions and leaves a use-case-specific merge to the application.

Bernd Ruecker frames the choices as ignoring an inconsistency, apologising for it, or resolving it, and calls picking one a business decision that IT cannot make alone. It belongs before the incident, and it is where the promise is kept or explained.

The longer writes diverge, the harder resynchronising becomes, which is the case for fencing, against unconfirmed promotion, and for designs where repeating a write is harmless.