Course Content
Mobile System Design Interview
11 sections · 23 lessons
Cheat sheet: patterns across the case studies and how to keep practising
The course's claim is that a small number of patterns recur everywhere. The first half of this lesson is the evidence, and it is the most useful page here for a candidate facing an unfamiliar prompt.
The second half is about what happens after you finish reading. Reading this course does not make you good at the round. Forty-five minutes of designing, several times, does.
Where each pattern appeared
| Pattern | Feed (S4) | Chat (S5) | Trading (S6) | Library (S7) | Hotel (S8) | Drive (S9) | Video (S10) |
|---|---|---|---|---|---|---|---|
| Offline-first (UI reads local) | ● | ● | ○ | ● | ◐ | ● | ◐ |
| Outbox for pending writes | ● | ● | ✗ | — | ✗ | ● | — |
| Optimistic update + rollback | ● | ● | ✗ | — | ✗ | ● | — |
| Cursor pagination | ● | ● | — | ● | ● | ● | ● |
| Coalescing high-frequency events | ◐ | ○ | ● | — | — | ● | ● |
| Resumable chunked transfer | — | ● | — | — | — | ● | ● |
| Idempotency key on writes | ○ | ● | ● | — | ● | ● | — |
| Two-transport handoff (socket ⇄ push) | ○ | ● | ◐ | — | — | ◐ | — |
| Delta sync with a change token | — | ● | — | — | — | ● | — |
| Conflict resolution | — | ◐ | — | — | — | ● | — |
● central · ◐ present · ○ minor · ✗ deliberately rejected · — not applicable
What the rejections teach
The ✗ cells are the most instructive part of the table. Trading and hotel booking both could queue writes in an outbox and both deliberately do not, because a market order or a payment executed an hour late at an unknown price is worse than one that never happened. Same pattern, same architecture, opposite decision — driven entirely by what the write costs if it lands late.
That is the answer to give when an interviewer asks "would you use an outbox here?" The question is never whether the pattern exists. It is whether a delayed write is acceptable.
What triggers each pattern
| If the prompt contains… | Reach for |
|---|---|
| A list of remote content | Cursor pagination, offline-first, image downsampling |
| A user creating or changing something | Outbox, optimistic update with rollback, idempotency key |
| "Real time", "live", "instant" | Two-transport handoff, and ask about backgrounded delivery |
| Updates faster than a person can read | Coalescing at a fixed flush rate |
| Files, media, or anything over ~20 MB | Resumable chunked transfer on a system transfer service |
| The same data on two devices | Delta sync with a change token, then conflict resolution |
| Money, orders, or anything irreversible | Idempotency key, explicit unknown state, reconcile — never blind retry |
| "Works offline" | Metadata separate from content, and a per-feature offline table |
Practising and going further
Knowing the patterns is recognition. Using them under a timer is the skill, and it only comes from practice.
Design the apps on your own phone
The best practice material is already installed. Pick one and give it a real 45 minutes with the protocol from How to use this course.
Good ones to start with, roughly in order of difficulty:
| App type | What it exercises | Closest section |
|---|---|---|
| A weather app | Caching, staleness, location permissions | 4 |
| A podcast app | Downloads, background audio, playback position | 10 |
| A ride-hailing app | Live location, battery, state machine across a trip | 6 + 8 |
| A food delivery app | Multi-step flow, live tracking, payment | 8 |
| A photo backup app | Background upload, storage, conflict | 9 |
| A collaborative notes app | Sync, conflict, offline editing | 9 |
| A photo editor | Memory, large images, undo history, export | 3 + 4 |
For each: write the questions, the API contract, the layer diagram, the storage design, and the six constraints. Then open the real app, turn on aeroplane mode, and see what it actually does. That last step teaches more than the design did — real apps make trade-offs you will not predict, and the ones that surprise you are the ones worth understanding.
The self-assessment rubric
Score your own attempt out of four, one point each:
- Architecture. Did you name a single source of truth, and does the presentation layer avoid touching the network?
- Constraints. Did you cover all six, with a number attached to at least three?
- API and data flow. Could you trace one item from response to pixel, naming every store on the way?
- Platform judgement. Did you name a platform limit unprompted and design around it correctly?
Three or four is interview-ready. Two means you have the structure and not the depth — that is usually a Section 3 problem, so go back to the relevant lesson rather than doing another mock.
The deep dive that often follows
This round is frequently paired with a platform-specific technical interview in the same loop. It typically covers concurrency and threading on your platform, the view and activity lifecycle, memory management and reference cycles, the rendering pipeline and how to profile a dropped frame, and testing strategy.
That is a different body of knowledge from this course and worth preparing separately. The overlap is real, though: the memory arithmetic in Images and media, the background execution limits in Background work, and the main-thread budget in Scroll performance all come up in both.
Where to go next
System Design Interview gives you the server half of every case study here — the news feed, chat, YouTube, Google Drive, hotel reservation, payment, and stock exchange designs. Reading the matching section after each case study here is the fastest way to become someone who can hold both halves of the conversation, which is what a senior mobile engineer is expected to do.