How does offline sync work?

Sync starts from the idea that there is more than one copy of the data. Each device holds its own copy, called a replica, and reads and writes it directly. When devices are connected they exchange changes quickly; when they are not, each replica moves forward on its own. Sync is the process of bringing replicas that moved apart back into line.

There are two ways to tell another device what happened. A device can send its whole current state and let the other side work out the difference, which is simple but heavy, and it loses information about who changed what. Or it can keep a log of the individual changes, often called operations or deltas, and send only those.

Most sync systems record changes. A change such as “set the status of job 17 to done” is small to send, and it carries enough context for the receiver to combine it with changes made elsewhere.

When two replicas meet, each needs to know which changes the other has not seen. Sending everything every time would waste bandwidth, which matters on a slow or metered link.

The usual tool is a version summary. Each replica numbers the changes it makes, and keeps a small record of the highest number it has seen from every other replica, sometimes called a version vector. Comparing two summaries shows exactly which changes are missing on each side. The idea builds on Leslie Lamport’s 1978 paper on ordering events in a distributed system, which showed how to order events with logical clocks instead of trusting each device’s wall clock.

This matters because device clocks disagree. A phone that has been offline for a week may be minutes out. Sync that relies on wall-clock time alone can put changes in the wrong order.

Receiving the right changes is half the job. The other half is applying them so that every replica reaches the same result, whatever order the changes arrive in. This property is called convergence, and systems that guarantee it once all changes have been delivered are called eventually consistent.

There are a few common ways to get there:

• A single authority. Devices send changes to a server, the server decides the final order, and devices take its answer. Simple, but it needs the server.
• Revisions with a deterministic winner. Some databases, such as Apache CouchDB, keep competing revisions of a record and pick the same winner on every replica, while keeping the others available for the application to resolve.
• Merge-friendly data types. Conflict-free replicated data types (CRDTs) are designed so that concurrent changes can be applied in any order and still produce the same result, with no coordinator.

When two changes touch the same thing, the system needs a conflict rule. How are sync conflicts resolved? covers the options.

The same mechanism works whoever the other replica is. A phone can sync with a server when it has a connection, with another phone over Bluetooth when neither has one, or with a relay that passes changes between devices that are never online at the same time. Because each exchange only sends what is missing, a change can travel through several replicas and still arrive once.

Sync makes copies agree. It does not decide whether a change was allowed, or whether the combined result makes business sense. If two technicians each claim the last spare part while offline, both copies will converge on a state where the part is claimed twice. Rules like stock limits, exclusive assignments, and approvals still need an authority, usually the backend, and a way to tell people when an offline action was turned down.