Worked case studies for mobile system design interviews and real projects: payments, wearables, chat, feeds, live tracking, uploads and safe releases.
Most system design guides are about servers. Mobile rounds ask different questions:
- What happens if the app is killed after the user entered their UPI PIN but before the result came back?
- How does a fitness band's data reach the cloud exactly once, after a week offline, with a drifting clock?
- How does a chat stay in order when phones' clocks are wrong and the network keeps dropping?
- How do you ship safely when a mobile release can't be rolled back?
Each case study answers questions like these with diagrams, data models, APIs, failure modes and trade-offs, the way you'd explain them in an interview.
📖 Read it as a website, with search and dark mode, or browse the Markdown below.
Start here
- The framework: seven steps for any mobile design round, and the common mistakes
- Building blocks: offline-first reads, the outbox, conflicts, real-time updates, pagination, caching, tokens, background work
- Cheat sheet: one page for the night before
Case studies
| Case study | Difficulty | You'll practise |
|---|---|---|
| UPI payments app | 🔴 Senior | Payment state machines, idempotency, reconciliation, device binding |
| Wearable health-data sync | 🔴 Senior | Bluetooth LE, background limits, deduplication, time zones, HealthKit and Health Connect |
| Offline-first chat | 🟡 Mid – 🔴 Senior | Outbox, ordering with sequence numbers, receipts, sockets and push |
| Infinite news feed | 🟢 Junior – 🟡 Mid | Cursor pagination, images, video, smooth lists, optimistic likes |
| Live ride tracking | 🔴 Senior | Location streams, trip state, smooth maps, battery |
| Resumable video upload | 🟡 Mid – 🔴 Senior | S3 multipart upload, presigned URLs, background transfers |
| Feature flags and staged rollouts | 🟡 Mid – 🔴 Senior | Remote config, kill switches, experiments, forced updates |
Every case study has the same sections: requirements → estimates → architecture → data model → API → deep dives → failure modes → trade-offs → interview follow-ups.
- Preparing for an interview: read the framework, then for each case study read only the requirements, close the page and design it yourself in 45 minutes. Then compare, focusing on the failure modes you missed.
- Interviewing others: each case study's follow-up questions make good probes, and the failure-mode table is a ready-made rubric.
- Designing a real feature: the building blocks and failure-mode tables work as a review checklist.
The designs are platform-neutral, with notes where Android, iOS and Flutter differ.
stateDiagram-v2
[*] --> Draft
Draft --> Submitting: PIN entered
Submitting --> Pending: 202 from backend
Submitting --> Unknown: timeout or app killed
Unknown --> Pending: status check finds it
Unknown --> Failed: never started
Pending --> Success
Pending --> Failed
Pending --> Reversed: debited, then refunded
The Unknown state is the one most designs forget. Read why it matters →
Corrections, better trade-offs and new case studies are welcome. See CONTRIBUTING.md, or start a discussion about a design you'd approach differently.
- Flutter Architect Handbook: 67 interview questions from Dart basics to architecture and leadership
- flutter-production-starter: a template app that applies many of these patterns
- upi_kit, ble_gatt_parser, ble_device_simulator: open-source Dart packages used in the payments and wearable case studies
MIT. See LICENSE.