Mobile system design
Mobile system design interview preparation
A platform-aware framework for iOS, Android and cross-platform system design interviews.
Mobile System Design Blueprint (book, from $199)
Mobile system design: what matters most
Mobile system design interview preparation should cover the client as a distributed system endpoint with limited battery, storage, connectivity and execution time. Begin with the user journey, freshness and offline expectations. Define state ownership and a local source of truth. Then design network contracts, pending writes, synchronization, conflict handling, caching, pagination, security, observability and migration. Explain platform differences only where they change the design.
The interview is not a contest to draw the most services. It tests whether requirements lead to defensible choices and whether the candidate can predict failure on real devices. Finish every design with measurement, staged rollout and the first assumption you would validate.
The mobile design sequence
Use the same sequence under pressure so important concerns are not lost.
- Clarify journeys and constraints
- Define state and source of truth
- Draw reads, writes and boundaries
- Design offline and synchronization
- Cover performance, security and observability
- Plan migration, rollout and validation
Mobile is not a small backend
The client owns user interaction, local state and a fallible connection to remote truth. It may be several versions behind and cannot be patched instantly.
A design that ignores lifecycle, background limits and local migration is incomplete even if the backend diagram scales. For a protocol change, ask what older installed clients will receive, and whether a remote flag can undo data already written.
Controlled Change gives this its own chapters: why mobile is different, and schema evolution and version skew.
Keep one operation visible
Trace one user operation through the whole drawing, such as editing a note offline. The device can confirm the edit is retained locally. Only the server can confirm it was accepted. Show those as two states, and name the account each pending edit belongs to.
Then interrupt it. If the server accepts the edit and the connection closes before the response arrives, the client knows less than the server. Reconciliation has to establish the result without treating the unknown outcome as a new user action.
Expect one changed constraint. If the user switches accounts before pending changes are sent, that work belongs to the first account, and the next account must not send it with different credentials. Revise that one boundary instead of restarting the answer. A second device changes the conflict rule. A large attachment changes storage and transfer recovery.
How senior answers differ
Senior candidates name tradeoffs and uncertainty. They separate correctness from optimisation and explain how telemetry will validate assumptions.
They also keep the user experience visible. A retry policy is not complete until the answer says what the user sees and can safely do.
