Offline support starts with a user action, not a database choice. List the operations people must complete without connectivity and decide which ones can wait for the server. Reading cached orders and submitting a new payment have very different requirements.
Make state explicit
A write may be local, queued, sending, confirmed or failed. Keep these states in the data model and show clear feedback. A spinner alone cannot explain whether it is safe to close the screen.
Avoid accidental duplicates
Assign a stable operation identifier before the first request. The server must use that identifier to avoid repeating an operation after a timeout and retry. A client-only flag is not enough when the response is lost.
Plan conflicts
Decide what happens if the record changes on another device. Some changes can merge; others need a fresh server value or a person’s decision. Document this for each entity.
Test interruption
Try airplane mode, process termination, stale credentials and a server error during sync. Verify that the UI preserves intent and explains the next action. Measure success by recovery behavior, not just whether cached data appears.