Offline merge

Offline sync accepts edits on every copy and merges them when the link returns. Last write wins keeps one side, and it dropped 4,000 edits in the mini board. A vector clock keeps the concurrent versions so that the app can merge them.

Play a level

See it on the board

The same traffic runs on two boards. The simulator measured both when this page was built.

Board to show
TCPMobile usersNode API1 vCPU · 1 GBKey-value s…1 vCPU · 1 GB × 3
HTTP/2TCPMobile usersNode API1 vCPU · 1 GBKey-value s…1 vCPU · 1 GB × 3
Last write wins: misses a goal
TCPMobile usersNode API1 vCPU · 1 GBKey-value s…1 vCPU · 1 GB × 3
HTTP/2TCPMobile usersNode API1 vCPU · 1 GBKey-value s…1 vCPU · 1 GB × 3
Vector clock keeps both versions: meets the goals
See it on the board
Measure Goal Last write wins Vector clock keeps both versions
Lost writes none 4,000 Fail 0 Pass
Error rate under 0.1% 0% Pass 0% Pass
Split-brain writes at least 1,000 4,000 Pass 4,000 Pass
Monthly cost 16 USD/mo 16 USD/mo
p99 latency 70 ms 70 ms

Key numbers

Default part values and network values from the catalog. The mini board has a link failure of 30 s and 200 edits/s.
NumberValue
Operations per second, one store30,000 ops/s
Store operation, median0.3 ms
Mobile 4G round trip, slow end90 ms
Read and write quorumsLeft and right arrows change R. Tap to change W.

W 3 + R 3 of 5 · every read sees the last write

How it works

A phone app must work without a link. The user edits notes on the train, and the edits stay on the phone until the link returns. Meanwhile the cloud copy can change too. When the two sides meet, they have each made changes that the other has not seen. These are concurrent edits.

You have three ways to treat them. You can reject edits made offline, which loses none but fails the user. You can keep one side, usually the newest by time. This is last write wins, and it silently drops the other side. Or you can keep both versions and merge.

In the mini board the phones and the cloud lose each other for 30 s, and 200 edits/s keep coming. The app must take at least 1,000 edits on both sides, reject none and lose none. Rejecting edits makes about one third of requests fail. Last write wins accepts all edits but drops 4,000 of them in this run.

A vector clock tracks which edits each side has seen. It can tell that two versions are concurrent, not ordered. The store keeps both, and the app merges them, for example by joining the text or by asking the user.

This costs more storage and more code. Pick the merge rule for each kind of data.

In the levels you pick the clock and check lost edits and errors.