Course Content
Mobile System Design Interview
11 sections · 23 lessons
Cheat sheet: the framework, decision tables and constraint checklist
Everything from Section 2 (A Framework for Mobile System Design), compressed to what fits on a single sheet, followed by the four decisions that come up in almost every design and the six constraints you must cover before you finish. Read it the evening before an interview, not for the first time.
Each part is a lookup, not an explanation. If a row does not make sense on its own, that is the signal to go back to the lesson it came from.
The seven steps and their budget
| # | Step | Min | The one thing to produce |
|---|---|---|---|
| 1 | Clarify requirements and scope | 5 | In-scope list, out-of-scope list, stated assumptions |
| 2 | The API contract | 5 | Two or three endpoints with real field names |
| 3 | High-level client architecture | 10 | The layer diagram, with the repository named |
| 4 | Data flow and persistence | 10 | What is stored, where, and how it is invalidated |
| 5 | Deep dive | 10 | Data structures, algorithm, failure cases, numbers |
| 6 | Constraints | 3 | Six sentences, one per constraint |
| 7 | Edge cases and close | 2 | Two or three specific cases, then what you would build first |
The clarifying questions, in priority order
- Which platforms, and what minimum OS version?
- Which parts work offline? (Press for a per-feature answer.)
- What network conditions are we designing for?
- Are low-end devices in scope?
- Is there an existing backend, or am I designing the API too?
- How large is the data — typical and worst case?
- How stale can this data be before it is wrong?
The sentences worth memorising
- The boundary: "I'll specify the API contract I want, and assume the server works unless you'd like me to design it."
- The architecture: "The user interface reads from local storage and never from the network. The network's only job is to write into local storage."
- The platform limit: "A backgrounded app is suspended, not slowed, so nothing time-critical can depend on background work."
- The retry rule: "I won't retry a write without a client-generated idempotency key."
- The close: "If I had one week I'd build X first, and I'd measure Y."
Decision tables
Four decisions come up in almost every mobile design. Each one has a small number of options and a single requirement that decides between them.
Transport: how data reaches the client
| If the requirement is… | Choose | Because |
|---|---|---|
| Updates every few minutes, tolerant of delay | Polling | Simplest thing that works; nothing else earns its complexity |
| Server-to-client only, near real time | Server-sent events | Real-time without owning a socket's reconnect story |
| Two-way, sub-second, client also sends | WebSocket | The only option that is genuinely bidirectional and cheap per message |
| Must reach the app when it is not running | Push notification | The only one that does — and it is best-effort |
| Very high frequency (many per second) | WebSocket plus coalescing | The transport is the easy half; see Throttling and coalescing updates |
The mobile-specific rule underneath all of it: four of the five stop working when the app is backgrounded. Real designs use two transports and hand off between them.
Persistence: where data lives on the device
| Data | Store | Ceiling |
|---|---|---|
| Preferences, sync tokens, flags | Key-value | Kilobytes — it is read before the first screen draws |
| Anything queried, sorted, or observed | Relational database | Megabytes to a few hundred megabytes |
| Images, video, documents, downloads | Files, with a row pointing at them | Budgeted and evictable |
| Tokens, encryption keys | Secure store (hardware-backed) | Credentials only |
| Pending user actions | Database (outbox table) | Never evicted |
The last row is the one people get wrong. Everything else is a cache and can be rebuilt from the server; the outbox cannot.
Pagination style
| If… | Choose | Because |
|---|---|---|
| The list changes while the user reads it | Cursor | Offset shows duplicates on insert and skips on delete |
| The list is static and you need "page 7 of 40" | Offset | Random access is the one thing cursors cannot do |
| A total count must be shown, positions are stable | Offset with placeholders | Accurate scrollbar; incompatible with cursors |
| Paging in both directions (chat history) | Cursor, with prev and next keys | Design it in from the start; adding it later is a breaking change |
Default to cursor. The exceptions are narrow and you will know when you are in one.
Conflict resolution
| If losing the local change costs… | Choose | Example |
|---|---|---|
| Nothing | Last-write-wins | Read state, a theme preference |
| Nothing, and the server derives it | Server-wins | Computed counts, entitlements |
| Something, but the fields are independent | Field-level merge | A rename on one device, a move on another |
| Real user work | Conflict copy — keep both | A document, a photo edit, a note |
| Real work, and duplicates are unacceptable | Prompt the user | Rare; use sparingly, batch them |
Say the reasoning, not just the choice. "Last-write-wins, because losing a read flag costs nothing" scores; "last-write-wins" alone does not.
The constraint checklist
Six things to address in every answer. Ninety seconds, one sentence each, and omitting one is noticed.
The six, with the sentence to say
1. Network. Unreliable, variable from 20 ms to several seconds, and often absent.
"Reads come from the local store, so the screen renders with no network. Writes go into a persisted outbox that drains on reconnect."
2. Battery. Radio wake-ups cost more than payload size, and the tail keeps the radio energised for seconds after each transmission.
"We batch requests rather than sending them individually, and drop from a socket to push when the app is backgrounded."
3. Memory. A hard ceiling enforced by process termination, and images are the usual cause.
"Images are decoded downsampled to the display size — a full-resolution photo is about 48 MB in memory — and lists recycle their views."
4. Storage. Shared with everything else on the device and finite.
"The cache has a stated ceiling, evicted least-recently-used, with the outbox and pinned content exempt, and the user can see and clear it."
5. Background execution limits. A backgrounded app is suspended, then killed.
"Sync is a deferred job that may not run for hours, so nothing the user is waiting on depends on it; long transfers go to the platform's transfer service."
6. Process death. Routine, not exceptional.
"The screen position, any draft the user has typed, and the outbox are all persisted, so a relaunch restores where they were."
How to deliver it
Do not deliver it as a list at the end if you can avoid it. The stronger pattern is to attach each constraint to the decision it caused, as you make that decision — "I'm batching these because of the radio tail" — and then use the final ninety seconds to cover whichever of the six have not yet come up.
If time is short, the list at the end still scores. Silence does not.
The four you can add for extra credit
Not required, and each is a strong signal when it fits:
- Thermal. Sustained load throttles the processor, so a design that is fast for thirty seconds may not be fast for ten minutes.
- Metered data. Not the device's cost but the user's, which makes it a product decision. Central in Sections 6, 9, and 10 (trading, Drive, and video).
- Permissions. Notifications, storage, location, and camera can all be declined, and the feature must still function.
- App size. Download size affects install conversion, and it is a real constraint on which libraries you can afford.