Offline data storage and sync strategy

WHAT THIS TESTS The interviewer wants to see that you understand offline-first architecture: durable local persistence, a reliable sync mechanism, connectivity detection, and conflict handling, not just an in-memory cache.

A GOOD ANSWER COVERS First you persist locally so data survives app restarts and crashes. Options include SQLite (via expo-sqlite or react-native-sqlite-storage), WatermelonDB for larger relational datasets, or MMKV/AsyncStorage for simpler key-value needs. Each locally created record gets a sync status, for example pending, and ideally a client-generated UUID. You maintain an outbox or mutation queue describing pending operations. You detect connectivity with NetInfo, subscribing to changes so you know when the device comes back online; you can also retry opportunistically when the app foregrounds. On reconnection you flush the queue in order, sending each mutation to the server, and on success mark the local record synced and store any server-assigned id. Failures are retried with exponential backoff. Crucially you handle conflicts, using updatedAt timestamps, version numbers, or a last-write-wins or merge policy, and you make server endpoints idempotent (using the client UUID or an idempotency key) so a retried request does not create duplicates.

COMMON WRONG ANSWERS Keeping data only in Redux or component state loses it on restart. Ignoring connectivity detection and hoping requests fail gracefully wastes battery and yields a poor UX. Skipping conflict resolution causes lost updates when the same record changed on multiple devices. Not making writes idempotent produces duplicates when a retry follows a request that actually succeeded.

LIKELY FOLLOW-UPS What about ordering and dependencies between queued mutations? Process them in order or topologically sort dependencies. How do you avoid duplicate sends? Idempotency keys and marking in-flight items. Which conflict policy? Depends on domain; last-write-wins is simple, CRDTs or server merge are stronger.

ONE CONCRETE EXAMPLE A notes app stores a new note in SQLite with a UUID and status pending. NetInfo reports the device is back online, so the sync service reads pending notes, POSTs each with its UUID as an idempotency key, marks them synced on a 2xx response, and retries with backoff otherwise, so no note is lost or duplicated.