Designing an offline-first app

Mobile system design Senior Kotlin 2.0+ API 24+ Reviewed By Best Latest Apps

Order the steps

Order what happens when a user edits a note offline.

  • Apply the server's result and clear the pending flag
  • When online, send the change with its ID and version
  • Write the edit to Room marked as pending
  • Enqueue unique sync work with a network constraint

Choose an answer, then open Show answer below to check it.

Show answer

Answer: C D B A

  1. Write the edit to Room marked as pending The UI updates at once.
  2. Enqueue unique sync work with a network constraint WorkManager waits for connectivity.
  3. When online, send the change with its ID and version The server can spot conflicts.
  4. Apply the server's result and clear the pending flag Local and server agree.

30-second answer

Make the local database the single source of truth: the UI observes Room, and the network only updates the database. User changes are written locally first with a 'pending' state and queued for sync with WorkManager under a network constraint. On sync, send changes with IDs and versions so the server can detect conflicts, then pull and merge server changes.

Practise saying it · 45 s. No recording, just a timer

Design an offline-first app.

Say your answer out loud, then check which of these points you covered:

  • Local DB is source of truth
  • Write locally, queue sync
  • WorkManager with constraints
  • Conflict rules and versions
  • Idempotent retries

Deep dive

Pick a conflict rule per data type: last-write-wins, server-wins, or merge fields.

Client-generated IDs (UUIDs) avoid duplicate creates when retries happen.

Idempotency keys make retried requests safe.

Show sync state so users know what's not yet saved to the server.

Common mistakes

  • UI reading from the network and caching as an afterthought.
  • Deleting pending changes on logout without warning.
  • Retrying non-idempotent requests and creating duplicates.

Senior take & follow-ups

Draw the data flow: UI ← Room ← sync ← network. Then conflicts, IDs and retries.

Follow-up questions

Think of your answer first, then open the hint.

  1. How do you stop duplicates when a retry succeeds twice?

    Show hint

    Client IDs or idempotency keys so the server ignores repeats.

  2. Where does sync run?

    Show hint

    In WorkManager with a network constraint, so it survives process death.

Compare on iOS: Offline-first architecture Same design; only the database and scheduler APIs differ.

Related questions

Suggest a fix if something here is wrong or out of date.