Android system design
Android system design interview guide
Design for lifecycle, process death, constrained background work and unreliable networks from the beginning.
Mobile System Design Blueprint (book, from $199)
Android system design: what matters most
An Android system design interview should define the source of truth, state ownership and data flow before choosing libraries. Clarify offline behaviour, process death, background constraints, consistency, security and supported devices. Explain how Room, the network layer and WorkManager cooperate without creating duplicate writes or stale UI. Cover pagination, cache policy, idempotency, conflict handling, authentication refresh, migrations and observability.
Compose or Views are presentation choices inside the larger system. A senior answer also describes rollout, compatibility and what the user sees during partial failure. The design is credible when every component has an owner, a lifetime and a recovery path.
Model the device as a system
The app can be killed, connectivity can change and scheduled work can run later than expected. Treat those as normal conditions.
- Local source of truth
- Pending mutation queue
- Idempotent server contract
- WorkManager constraints
- Authentication refresh ownership
- Schema and app-version migration
Separate freshness from correctness
Some screens can display cached data with a timestamp. Others must block destructive actions until fresh state is confirmed. State the product rule explicitly.
This distinction drives cache expiry, sync urgency and UI messaging.
Rehearse one case: an upload whose response is lost
Take a file attachment. The user picks it, leaves the screen, and the process dies. The upload is a durable operation owned outside the screen. The screen observes its state, and WorkManager gets the chance to run it. Scheduling is not acceptance.
Now ask what the app may claim. The server can accept the file and the connection can close before the response arrives. A retry with a new operation id can create a second attachment. So the client needs an account-scoped operation id, and the server needs to deduplicate on it or let the client look up the outcome. Until that answer arrives, the UI shows the upload as unresolved, not failed.
Three more checks:
- A stored content URI does not prove the file is still readable. Decide whether the app copies the bytes or keeps the reference.
- A stopped worker must preserve cancellation instead of reporting an ordinary failure. WorkManager ignores the result of a stopped worker, so the operation record needs its own recovery rule.
- If account A signs out with uploads pending, account B must never send A's bytes with B's credentials.
Explain operations
Name metrics for sync age, failed writes, database migration, cold start and crash-free sessions. Add structured logs that connect a user-visible failure to the responsible layer.
Finish with staged release and rollback. Architecture includes how the team changes the system safely.
