Android system design
Android System Design Interview Guide
Design for lifecycle, process death, constrained background work and unreliable networks from the beginning.
Short answer
What matters most
An Android system design interview should define the source of truth, state ownership and data flow before choosing libraries. Clarify offline behavior, 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.
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.
