18. Three edits that compose, and one that always wins
Increment, add-to-set and pull compose; delete leaves a sticky tombstone; a write never fails because of another writer, and in exchange no rule can span concurrent writers.

18. Three edits that compose, and one that always wins

Increment, add-to-set and pull compose; delete leaves a sticky tombstone; a write never fails because of another writer, and in exchange no rule can span concurrent writers.

It says what you can and cannot model.

Not every edit is last-writer-wins. An increment is a counter. Two offline increments both apply.

Add-to-set and pull are set operations. Two concurrent adds both land.

Delete is different. Delete wins absolutely. A deleted record leaves a tombstone, and the tombstone is sticky.

Any later edit to that record is dropped. The local writer is told. Nobody else needs to be.

What you cannot have is a rule across writers. A balance that must stay above zero cannot be enforced by two devices offline. Model it as a counter, or accept that both decrements land.

A write never fails because someone else wrote first. In exchange, every rule must be a commutative operation or a per-field overwrite.

Check yourself. Two devices decrement a counter offline. What happens?

Do you like what you are reading? Subscribe to receive updates.

Unsubscribe anytime

Comments