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

Connections0

Connections show where other documents or comments link to this document.

Related documents

Loading connections…