Offline-capable state architecture

WHAT THIS TESTS Whether you can design both offline reads and offline writes, including the hard parts: queuing, optimistic updates, synchronization, and conflict resolution, rather than just caching responses.

A GOOD ANSWER COVERS Separate persistence of read state from a durable mutation queue. For reads, Redux Persist rehydrates the store from AsyncStorage on launch, which suits modest state; for large relational datasets WatermelonDB or SQLite scale far better with lazy loading and indexed queries. For writes, every mutation is enqueued with a client-generated id and a pending status, the UI updates optimistically, and a sync engine drains the queue when NetInfo reports connectivity. On success you replace the temporary id with the server id; on failure you roll back or mark for retry with backoff. Conflict resolution needs a strategy: last-write-wins, version numbers, or server-merge.

COMMON WRONG ANSWERS Caching only GET responses and calling the app offline-capable, ignoring the write path, skipping conflict handling, or persisting the entire store including ephemeral UI state. Using AsyncStorage as a database for thousands of relational rows is another common mistake.

LIKELY FOLLOW-UPS How do you generate stable temporary ids? How do you detect and resolve conflicts? How does WatermelonDB's sync protocol with pulled and pushed changes work? How do you avoid double-applying a replayed mutation?

ONE CONCRETE EXAMPLE A user creates a note offline. The app assigns a UUID, stores the note with status pending, and shows it immediately. NetInfo later reports online, the sync engine POSTs the note, receives the server id, swaps the UUID, and clears pending. If the POST returns a 409 conflict, the engine fetches the server version, applies the merge policy, and surfaces a non-blocking notice rather than silently dropping the user's edit.