What Offline-First Actually Looks Like in Field Operations

The Field Reality

A health officer in a rural LGA conducts household surveys using a government-issued tablet. The nearest cell tower provides intermittent 3G coverage — when it works at all. The officer needs to record data for 40 households per day, whether or not the network cooperates.

This is the use case that offline-first architecture was built for.

The Architecture

Local Database

We use SQLite (via Expo SQLite for React Native, sqflite for Flutter) as the local database on the device. The complete schema mirrors the server schema. All writes go to the local database first.

Sync Engine

A background sync process runs whenever connectivity is detected. It:

1. Queries the local database for unsynced records (those with synced_at IS NULL)
2. Batches them into a single API request (up to 100 records per batch)
3. Sends the batch to the server
4. Updates synced_at on successful confirmation

If the sync fails partway through, the next sync attempt picks up where it left off. Records are never sent twice (idempotency keys).

Conflict Resolution

When the same record is edited on two devices before either syncs — which happens in team environments — conflicts must be resolved. We use a last-write-wins strategy for simple fields and a merge strategy for structured data (arrays, maps).

For fields where both edits matter (comments, observations), we store both versions and flag the record for manual review.

Data Compression

A day's worth of survey data might be 500 records with attached photos. Before syncing, we compress the batch and thumbnail images to reduce bandwidth consumption. Full-resolution images sync in a separate, lower-priority background process when the device is on WiFi.

What This Looks Like to the User

From the field officer's perspective, the app always works. They open it, it shows their work queue. They complete a survey, it saves. They submit it, they see a confirmation. Whether that data is on the server or queued locally, the experience is identical.

The sync status indicator in the corner shows them how many records are pending sync — but this is informational, not blocking.

Lessons From the Field

Design for the real device. Government-issued tablets in Nigeria are often 3–4 years old, with limited RAM and storage. Test on real device profiles, not developer machines.

Photo management is critical. Photos are the largest consumers of storage and bandwidth. Implement automatic cleanup of synced photos from local storage.

Handle time sync carefully. Offline devices can drift in their system clocks. Use server timestamps as the authoritative time for all records, not device timestamps.