Reference Architecture: Offline-First Field App
Product forces
Offline-first field apps optimize for continuity under weak networks, local data durability, conflict resolution, sync transparency, and recovery after long gaps.
Architecture sketch
Default decisions
| Area | Default |
|---|---|
| data | local database for required field workflow data |
| mutations | durable queue with idempotency keys |
| sync | explicit sync states, retries, and conflict policy |
| UI | visible offline, pending, failed, and conflict states |
| security | encrypted storage where sensitive data is cached |
| observability | sync success, queue age, conflict rate, data loss signals |
Critical risks
- Offline mode implemented as "catch fetch errors".
- No idempotency for replayed mutations.
- Hidden conflicts resolved silently.
- Sensitive data cached without classification.
- Users cannot tell whether work is saved locally or synced remotely.
Review checklist
- Which workflows must complete without network?
- What is stored locally and for how long?
- Are queued mutations idempotent and observable?
- What conflict policy applies per data type?
- Can users recover from failed sync without data loss?
Exercises
- Map offline-required and online-required workflows.
- Design a mutation queue schema for three field actions.
- Write a conflict resolution policy for editable records.
Source lens
Pair this with Part III offline/local-first chapters and the offline-first system-design prompt.