Offline sync is a product decision before it is a technical feature. These offline sync decisions determine what a client may read or write without the network, which actions are safe to queue, how competing changes meet, and what “done” means. Android’s offline-first guidance recommends a local data source for resilient reads and queued writes, while the Indexed Database specification illustrates a browser persistence option. The important work is not selecting a library. It is writing a contract that customers, support, product, security, and engineering can all interpret the same way.
Decide why offline matters
Offline capability earns its cost when network absence is common or when waiting would interrupt valuable work. Name the job and the consequence: a technician records inspection results in a basement, a salesperson reviews a catalogue on a flight, or a warehouse worker scans stock in a dead zone. Avoid promising “works offline” without defining the required dataset, duration, and actions. A read-only cache, an offline draft, and a queued command have different risk. The first design artifact should state the job, the user, the maximum offline period, the acceptable staleness, and the proof required after reconnection.
| Decision | Example choice | Why it matters |
|---|---|---|
| Offline duration | Up to one work shift | Sets retention and refresh expectations |
| Read scope | Assigned sites and open jobs | Limits local exposure and storage |
| Write scope | Notes and checklist results | Separates safe work from sensitive actions |
| Completion | Server confirmation required | Prevents local intent becoming false success |
Define local authority
For each entity, decide whether the client may create, edit, delete, approve, or only view it offline. A local draft can be authoritative for the user’s unfinished note, but not for a shared inventory count or entitlement. Mark records with source, version, fetched time, local modification time, and sync state. If a record is cached for convenience, it should not imply that the user is seeing the current server value. HTTP Semantics provides useful language for conditional requests and validators; the business rule still decides whether a stale version may be submitted or must be reviewed.
Choose conflict rules before screens
List the collisions the product can create. Two people may edit a service note, a device may change state while a technician is offline, or a manager may revoke access while a client holds cached data. For each entity, choose server-wins, client-wins, last-valid-version, field merge, or human review. Explain what the losing intent becomes; do not throw it away. Use a version or precondition so a client cannot overwrite a record it did not read. The rule should be testable in plain language and visible in the interface when it affects the user’s next action.
Plan storage, privacy, and migration
Local persistence changes the threat model. Decide whether data is encrypted at rest, how tokens are protected, what happens on logout, how a shared device is handled, and how attachments expire. Browser storage can be cleared or constrained; mobile storage can be unavailable or migrated between app versions. W3C Web Storage is a useful technical boundary, not a promise of unlimited durability. Keep schema migrations backward-compatible for queued operations, and build a safe reset path that preserves recoverable work instead of deleting it silently.
Design the queue and retry contract
Every queued operation should carry an idempotency key, target, actor, client version, payload, precondition, attempt count, last attempt, and classification. Retry transient transport errors with bounded backoff; stop on authorization, validation, or conflict errors. W3C Service Workers shows why deferred work must be resumable and scheduled within platform limits. Do not retry a command blindly when the first request may have succeeded. Provide a reconciliation step and a visible age for operations that cannot converge. Before the first build, decide who can clear, replay, cancel, or escalate a queue item.
Make these decisions concrete with a short scenario set. Write what happens when a user edits offline, a second user edits online, the first user reconnects, and the original permission has changed. Then repeat the scenario with a lost device, a schema update, and a duplicate request. Compare the result with offline sync in production and connected field service portals to ensure the planning choices survive a real job.
Secure reconnection
A reconnecting client may be using an old token, stale role, outdated policy, or a different device posture. Re-authenticate when required and re-authorize each operation on the server. Do not trust client timestamps for ordering sensitive events; use server receipt and business versioning. Protect replay endpoints with idempotency and rate limits. Record accepted, rejected, conflicted, and superseded operations so an operator can explain why a local state changed. Security review should include the offline period, not only the connected session. Cached data is still data, and queued intent is still an attempted action.
| Question | Decision to document | Acceptance test |
|---|---|---|
| What is current? | Server version and freshness rule | Stale view is labelled |
| Who may act? | Authorization at receipt | Revoked user is rejected |
| What merges? | Entity and field policy | Conflict outcome is deterministic |
| What is complete? | Confirmation and closure state | Unknown outcome remains visible |
Decision review before the first build
Write the offline contract as acceptance criteria: which reads are allowed, which writes may queue, which conditions invalidate a local action, and what evidence proves completion. Include privacy, storage, migration, and support decisions. This turns a broad promise into a set of choices that can be tested with real users.
Before implementation, bring product, engineering, support, security, and a real user through the same offline scenarios. Start with a normal write, then interrupt the process, deliver a duplicate, introduce a server-side edit, revoke access, and inspect the final state. Make the planner describe the local view, server authority, and evidence support can retrieve. The purpose is not to eliminate every failure; it is to make each important failure bounded, visible, and owned.
Choose the next capability from the largest remaining ambiguity. It may be conflict explanation, a safe cancel path, a smaller cache, or a migration plan for old queued operations. Do not expand offline writes simply because a cached screen looks successful. Compare the result with what changes when offline sync moves into production and record the evidence that justifies the next build decision.
- Replay a write through interruption, duplicate delivery, and a server version change.
- Confirm an old client cannot bypass current permission.
- Review local storage and queue retention with a privacy owner.
- Measure time to confirmed outcome before calling the feature reliable.
If the team cannot state the conflict rule in one sentence, defer the write capability and ship a read or draft experience first. Delaying a risky action is a product decision, not a failure of ambition.
Write down what the team will not support offline in the first release. A clear exclusion protects users from assuming that every visible control is safe to use without current state.
Implementation boundary
Turn the planning choices into a small acceptance matrix before choosing a sync library. Include a normal local write, an interrupted write, a conflict, a revoked user, a cleared store, a migrated client, and a duplicate request. For each case, record the visible state, server result, support evidence, and permitted recovery action. This keeps the first build centred on business outcomes rather than on a generic background worker.
Do not hide the cost of offline capability in a future support queue. Estimate storage, attachment transfer, conflict review, privacy requests, client migration, and operational monitoring alongside feature work. A smaller offline scope with explicit confirmation may serve customers better than a broad scope that creates unbounded local state. Compare offline sync in production with device provisioning for connected systems before approving expansion.
- Name the local source and server source for every supported entity.
- Define the precondition that makes a queued action safe.
- Record how a user cancels, edits, or escalates an unresolved operation.
- Test the contract with the device, network, and storage limits customers actually have.
Plan support before implementation
Support needs to distinguish local, queued, server, and conflict states without asking a customer to guess. Expose operation ID, record ID, device ID, client version, queue age, last sync, and redacted server response. Give support safe actions with approvals: retry, cancel, hold, resolve, or request re-entry. Track queue age, conflict rate, rejected operations, local-storage failures, and time to confirmed outcome. Android’s offline-first guidance is a useful prompt to make recovery, monitoring, and operational readiness part of the design rather than an afterthought.
Key takeaways
- Start with the job and offline duration, not a generic offline promise.
- Define local authority and server authority per entity and action.
- Choose conflict and retry rules before building screens.
- Treat storage, privacy, migrations, and platform scheduling as first-class constraints.
- Make reconnection, support, and recovery observable from the beginning.
Frequently asked questions
What is the first offline sync decision?
Define the user job, maximum offline duration, allowed reads and writes, acceptable staleness, and the evidence that proves completion after reconnect. That scope determines the architecture.
Should the server always win conflicts?
Not always. Server authority may be right for shared state, while a local draft may remain the user’s work. Choose per entity and preserve losing intent for review or recovery.
How much data should be available offline?
The smallest set that lets the named job continue safely. Limit by assignment, time, sensitivity, and storage budget, and show when the local set is incomplete or old.
Conclusion
Before building offline sync, decide what the user may do, what the server must confirm, how competing intent is resolved, and how the team will recover. Those decisions create a smaller, safer build and prevent the first production outage from becoming the product specification.