Offline sync is the discipline of preserving useful work when a device, technician, or gateway cannot reach the central service. It is not simply caching a screen and posting it later. A sound design decides what can be done offline, which records are authoritative, how edits are identified, what happens when two parties change the same thing, and how a person sees unresolved conflict. Apache CouchDB’s replication and conflict model is a useful official reference because it treats divergent revisions as a normal state that applications must resolve. AWS’s Device Shadow service adds a useful distinction between desired and reported state. Together they frame the practical choices.
Define What Must Work Offline
List the tasks a user must complete without a connection and the tasks that must wait. A technician may inspect an asset, record a measurement, attach a note, and close a low-risk work item offline, while changing a safety limit or issuing a high-impact command may require current authorization. Set an offline time window and a maximum local dataset. Link to field service portals for connected systems when the sync boundary is part of a broader technician workflow. The first design decision is a safety decision: offline capability should preserve approved work, not create an unreviewed authority path.
| Offline action | Safe default | Why |
|---|---|---|
| Read assigned work | Allow with bounded cache. | Users need context to continue. |
| Record observation | Allow and timestamp locally. | Work should survive dead zones. |
| Edit shared status | Queue with version and author. | Concurrent edits need review. |
| Change critical policy | Require connection or explicit approval. | Stale authority can cause harm. |
Give Local Data a Durable Model
Local records need identifiers, version or revision, author, device identity, event time, local write time, sync status, and a retry or error state. Keep an outbox of changes separate from the read model so a failed upload does not erase the user’s work. The CouchDB technical overview illustrates why replication and local persistence need an explicit model rather than an assumption that the network will heal every gap. Encrypt sensitive local data, set capacity and eviction rules, and make the user aware when the local store is full or old. Do not rely on a UI memory cache for durable work. Define what happens after app restart, device replacement, logout, or a local database migration. A clear local model makes sync behavior testable instead of magical.
Choose the Authority for Each Field
Conflict resolution becomes easier when authority is explicit. A server may own work-order status, a device may own an observation timestamp, and a technician may own a note until a supervisor reviews it. Avoid declaring an entire document authoritative when fields have different owners. CouchDB’s eventual consistency overview explains that replicas can converge while applications still decide how to handle conflicts. Write the policy per field or operation: last writer, server wins, merge, append-only event, or human review. Never call silent overwrite a resolution without checking its consequence.
| Conflict type | Preferred treatment | User experience |
|---|---|---|
| Independent fields | Merge when validation passes. | Show combined result and provenance. |
| Same status field | Use version check or review. | Explain both edits before choosing. |
| Append-only observation | Keep both with event identity. | Show ordered history. |
| Critical command | Reject or require current authority. | Ask user to reconnect and confirm. |
Make Conflicts Visible
A conflict is not necessarily a system failure; hiding it is the failure. Show which record changed, who changed it, when each version was written, and which fields differ. Give a reviewer safe choices and preserve the discarded or superseded version for audit where the risk requires it. Apache CouchDB documents deterministic winning revisions and the need for application conflict handling; use that as a reminder that convergence alone does not establish business correctness. Add a reason code and resolution owner. A conflict queue that is never reviewed is just delayed data loss.
Make Retry Idempotent
Disconnected clients retry, and networks can deliver a response after the client believes a request failed. Every write needs an idempotency key or revision check, and the server should make duplicate handling explicit. Preserve local order where order matters, but do not assume network order equals business order. Back off retries, cap attempts, and move permanent failures into a visible queue. Test a timeout after server commit, a duplicate upload, a device clock jump, and a user editing while an older upload is pending. The retry contract should leave one understandable result, not multiple side effects.
Separate Desired, Reported, and Confirmed State
Offline users may queue intent while the device or service remains unaware. Use separate fields or records for desired state, reported state, and confirmed application. AWS IoT’s shadow model is useful here because it allows clients and services to work with state while a device is disconnected, but the same approach applies to field records. Show a command as pending until the target confirms it. Expire old intent where a stale instruction would be unsafe. A green interface should mean confirmed or explicitly acknowledged, not simply “saved locally.”
Protect Local and Sync Boundaries
Offline data is often more exposed because it lives on mobile devices, gateways, or laptops outside the central perimeter. Encrypt local storage, protect unlock credentials, minimize cached records, and support remote revocation or wipe where appropriate. Authenticate sync requests, authorize by tenant and assignment, validate uploaded records, and audit conflict resolution. A device that was authorized yesterday may not remain authorized today, so sync must re-check authority rather than replaying an old permit forever. Keep attachment handling separate from record metadata and use size limits to prevent a full local queue from becoming an availability problem.
Measure Sync Health
Track local queue age, pending record count, retry count, conflict count, upload latency, download freshness, failed validation, storage pressure, and the percentage of work completed offline. Segment by device model, application version, site, and network type without creating uncontrolled metric cardinality. An increasing queue may signal a dead zone, a server outage, an authorization change, or a client bug; the measure needs context. Give support staff a record-level sync status that does not expose sensitive payloads unnecessarily. Review unresolved conflicts as an operational workload, not just a technical metric.
Pilot with Disconnection by Design
Choose one field workflow and deliberately test airplane mode, app restart, battery loss, clock skew, partial upload, duplicate request, schema upgrade, and concurrent edit. Have a user complete meaningful work and then review the result after reconnection. Compare lost effort, conflict resolution time, and operator confidence with the online baseline. Read offline sync for growing teams for a related planning view. Do not widen the rollout until the team can find pending work, recover a failed record, explain a conflict, and prove that critical actions remain bounded.
Plan a user-facing recovery path for every sync state. A technician who sees a rejected record needs a way to correct and resubmit it; a supervisor who sees a conflict needs the versions and authority context to decide; support needs correlation without access to sensitive content. These flows should be designed with the same care as the happy path because disconnected work often surfaces when people are already under time pressure.
Set a maximum age for cached context and a maximum time for unresolved writes. When either limit is reached, the interface should explain what is no longer safe and what the user can do. This is better than allowing stale records to look current or leaving an outbox that quietly grows for weeks. Operational limits are part of the product promise.
Use reconciliation results to improve upstream work. Repeated conflicts may indicate a poor assignment model, a missing field-level authority rule, or a workflow that asks two roles to edit the same status. Repeated retry failures may indicate a payload size or authorization problem. Offline sync is not only a transport feature; it is evidence about how distributed work is organized.
A sync design should also state what happens when the user stops trying. Expire abandoned local work, retain enough history to explain the decision, and notify the right owner when a record cannot be reconciled. This prevents an old outbox from becoming a hidden source of commands or misleading status. Use offline sync checklist when converting the plan into a release review.
Reconciliation should preserve user confidence as well as data integrity. Show the local author, server version, timestamps, and next action in plain language. When a record is accepted, make that confirmation durable; when it is rejected, keep the original work available for correction rather than forcing the user to recreate it.
Practical Takeaways
- Define which tasks are safe offline and which require current authority.
- Give local work durable identifiers, revisions, provenance, and an outbox.
- Choose field-level authority and make conflicts visible instead of overwriting silently.
- Use idempotency and bounded retries for writes and uploads.
- Separate desired, reported, and confirmed state for disconnected actions.
- Measure queue age, conflicts, storage pressure, and real work completed offline.
FAQ: Offline Sync
Should conflicts always be resolved automatically?
No. Independent fields or append-only observations may be merged safely, while critical status, identity, or command changes may require a person. The rule should follow business consequence and preserve enough history to explain the result.
How much data should an offline client cache?
Cache the smallest bounded dataset that supports the approved workflow, with an expiry and eviction policy. More cached data increases privacy, storage, and stale-context risk. Make the user aware when a record is too old to act on.
Conclusion
Offline sync earns trust when it preserves useful work without pretending that disconnected devices have unlimited authority. Define the offline boundary, durable local model, field authority, conflict path, retry contract, and security controls before implementation. Then reconnection becomes a controlled reconciliation step rather than a surprise batch of side effects.