Last writer wins, per field: the simplest merge rule that works offline

When devices edit the same data while offline, the simplest merge rule that still works is "last writer wins, per field": each field keeps the value with the latest timestamp, and ties are broken by a fixed order so every device reaches the same result. It is boring on purpose. Its limits are just as clear: counters and lists need a different shape, not a cleverer clock.

This post explains the problem, the classic families of solutions (operational transformation and CRDTs), the rule Havenfold chose and why, and where that rule stops working. Havenfold is pre-alpha: do not use it for real data.

The problem: phones, a shared record, no network

Imagine a family notebook record called "Boiler" with fields for the service date and the technician's phone number. Using the example phones from Havenfold's demo: Alex's phone is offline and Alex changes the service date. Maya's phone is also offline and Maya changes the phone number. Later, both phones reconnect.

What should the record look like? Most people would say: the new service date from Alex, the new phone number from Maya. Now make it harder: Alex and Maya both change the service date to different values. Someone's change has to win, and every device must agree on whose, without asking a server and whatever order the changes arrive in.

Classic families: OT and CRDTs

Collaborative software has well-known approaches to this.

• Operational transformation (OT) transforms each incoming edit against edits it hasn't seen, so that applying them in different orders gives the same result. It is the classic approach for real-time text editing and is often implemented with a central server that orders operations.
• Conflict-free replicated data types (CRDTs) are data structures designed so that replicas converge without coordination. The 2011 paper by Shapiro, Preguiça, Baquero and Zawirski defines a CRDT as a data type that meets sufficient conditions for convergence under strong eventual consistency. Some CRDTs are very rich, for example for collaborative text.

For a family's structured records rather than shared text documents, a simple register per field is often enough. A "last-writer-wins register" is one of the simplest members of the CRDT family.

The rule Havenfold uses

Havenfold's record layer is specified in RFC-0001. Its summary says merging is "last writer wins at field level (HLC)" (translated from Turkish; the Turkish original prevails). In more detail:

• Per field: For each field, the larger value wins, compared first by the hybrid logical clock timestamp, then by the author's ID in byte order, then by the operation's ID in byte order. Even operations from the same author with the same timestamp are resolved deterministically.
• Deletion: A delete is written to the record's deletion marker with the same rule. Fields older than the deletion are ignored when reading. A later write can bring a deleted record back.
• Order independence: The order in which operations are applied doesn't change the result. When the set of valid operations changes, the state is recomputed.
• When the rule isn't enough: Where last-writer-wins at field level doesn't fit, such as counters or merging lists, the product stores each item as a separate record.

In the boiler example, Alex's date and Maya's phone number both survive, because they are different fields. If both changed the date, the later timestamp wins on every device.

Why a hybrid logical clock?

"Latest" needs a clock, and device clocks can drift or be set wrong. A hybrid logical clock (HLC), described by Kulkarni, Demirbas and colleagues in 2014, mixes physical time with a logical counter: it stays close to wall-clock time while still respecting the order of events a device has seen.

RFC-0001 uses it this way:

• Each device keeps a last timestamp and writes it to storage before sending an operation.
• When writing, the new timestamp is the larger of "now" and the next value after the last timestamp.
• When receiving, the device moves its last timestamp forward to at least the incoming one.
• If an incoming operation claims a time too far in the future, it is held until the local clock catches up. This changes when the operation appears, not the result.
• The timestamp is used only for merge order, never for permission decisions. Who may write is checked against the family's signed membership record.

Where last-writer-wins breaks

The rule is simple because it gives things up. It is worth being honest about which:

• Counters: If phones each add a feeding to "times the cat was fed today" while offline, last-writer-wins keeps a single change and loses the others. The fix in Havenfold is to make each feeding its own record and count the records.
• Lists: If people add items to the same shopping list field at the same time, a list overwrites the others. Again: each item becomes its own record.
• Text: People editing the same paragraph together need a text CRDT or OT. A field-level rule keeps a single version.
• Silent loss: When the same field really is edited by more than one device, the earlier edit disappears without a conflict prompt. For a family notebook, that is often acceptable; for some data it isn't, and the product has to model it differently.

Summary

• When devices edit data offline, they need a merge rule that gives the same result on every device in any order.
• Operational transformation and CRDTs are the classic families; a last-writer-wins register is one of the simplest CRDTs.
• Havenfold's record layer uses last writer wins per field, ordered by a hybrid logical clock, then author and operation IDs.
• Counters, lists and shared text don't fit that rule; Havenfold stores such items as separate records instead.
• Havenfold is pre-alpha, its RFCs are approved by the project lead alone, and it is not for real data yet.