Worked Answer: Offline-First Field App
Prompt
Design an offline-first field app where technicians inspect assets, capture notes/photos, update job status, and sync later on unreliable networks.
Clarify
Ask:
- What must work fully offline?
- What data is sensitive?
- What conflicts are possible?
- Are photos or large files required?
- Can multiple users edit the same job?
- What happens when permissions change while offline?
Architecture overview
Local-first model
| Concern | Decision |
|---|---|
| local store | IndexedDB or equivalent durable store with migrations |
| commands | append-only command queue with idempotency keys |
| media | separate upload queue with resumable strategy |
| conflict | domain-specific policies by object type |
| permissions | server revalidates during replay |
| diagnostics | redacted sync report for support |
State and data
| Data | Offline behavior | Conflict policy |
|---|---|---|
| assigned jobs | cached before shift | server wins for assignment removal |
| inspection checklist | editable offline | field-level or operation merge |
| job status | queued command | latest valid transition with audit |
| notes | editable offline | append or manual merge |
| photos | stored locally until upload | idempotent media upload |
Failure modes
| Failure | UX |
|---|---|
| sync delayed | "saved locally" with oldest unsynced age |
| permission revoked | command rejected with explanation |
| conflict | review panel with local and remote changes |
| storage full | block new media, preserve existing work |
| migration failure | safe recovery and support diagnostics |
Observability
Track:
- unsynced command count
- oldest unsynced command age
- conflict rate
- authorization rejects during replay
- local migration failures
- media upload retry count
- storage quota errors
Tradeoffs
| Decision | Tradeoff |
|---|---|
| durable local store | more complexity, protects offline work |
| command queue | easier replay/audit, requires schema discipline |
| manual conflict for high-value data | more UX work, less silent data loss |
| server permission recheck | possible offline rejection, safer security |
Strong close
The key is to be honest with users: distinguish saved locally, syncing, synced, conflict, rejected, and storage-full states. Offline-first is not a cache feature; it is a product contract with sync, conflict, permission, and recovery semantics.