Offline data persistence and mutation queue

WHAT THIS TESTS Whether you can architect the harder write path of offline support, not just read caching, including durability, ordering, id reconciliation, and idempotency.

A GOOD ANSWER COVERS For reads, persist fetched data to AsyncStorage for small state or SQLite/WatermelonDB for large relational data, hydrating the store on launch so screens render without a network. For writes, maintain a durable mutation queue persisted to disk so it survives app restarts; each entry has a client-generated id, the operation type, payload, and a status. When a mutation happens offline, append it and update the UI optimistically. A NetInfo listener detects reconnection and a sync worker drains the queue in FIFO order, replacing temporary ids with server-assigned ones in dependent records, retrying transient failures with backoff, and removing succeeded entries. Mutations should be idempotent or carry a request id so a replay after an ambiguous failure does not duplicate data.

COMMON WRONG ANSWERS Caching only GET responses, holding the queue purely in memory so it vanishes on restart, ignoring ordering between dependent mutations, or not reconciling temporary client ids with server ids. Skipping idempotency invites duplicate items when a request succeeds but the response is lost.

LIKELY FOLLOW-UPS How do you guarantee ordering when one mutation depends on another's server id? How do you make replays idempotent? How do you resolve conflicts if the server changed too? How does WatermelonDB's sync help?

ONE CONCRETE EXAMPLE Offline, the user creates a task. The app stores it locally with id tmp-9, status pending, and shows it. On reconnect, the worker POSTs the task, receives server id 512, rewrites tmp-9 to 512 everywhere it is referenced, and clears the queue entry. If the POST times out but actually succeeded, the carried request id lets the server dedupe, so retrying does not create a second task.