System Design Interview for Mobile Devs

Real-world analogy

What is it?

System design interviews evaluate your ability to design large-scale software systems. For mobile developers, this means designing not just the backend infrastructure, but the entire client-server architecture including offline support, caching strategies, and real-time communication. The interviewer assesses your ability to make and justify technical trade-offs at scale.

Real-world relevance

A mobile developer at a fintech company was asked to design a payment system in their interview. While backend candidates focused only on server architecture, she included: offline payment queuing, optimistic UI updates, retry logic with idempotency keys, local transaction history cache, and push notification for payment confirmations. She got the offer because her design was the most complete — it covered the full user experience, not just the server side.

Key points

• The 4-Step Framework — Every system design follows: (1) Requirements — functional and non-functional (2) High-Level Design — major components and how they connect (3) Deep Dive — detail 2-3 components the interviewer cares about (4) Trade-offs — what you'd do differently at different scales. Spend 5 min on each for a 20-min round.
• Requirements Gathering Is Half the Battle — Ask: 'How many users? What's the read/write ratio? Do we need real-time updates? What platforms (iOS, Android, web)? What's the latency requirement?' Writing down requirements on the whiteboard shows structure. Bad candidates jump straight to drawing boxes.
• Estimating Scale (Back-of-Envelope) — Key numbers to memorize: 1M users ≈ 10K concurrent. 1 KB per request × 10K QPS = 10 MB/s bandwidth. 1M records × 1 KB = 1 GB storage. 80/20 rule: 20% of data serves 80% of requests (cache this). Practice doing these calculations out loud.
• Mobile-Specific Design Considerations — Offline support (local DB + sync). Battery/data usage optimization. Push notification architecture. App size constraints. Screen size adaptation. These are your SUPERPOWERS in system design — most backend-focused candidates ignore them.
• The Components You Must Know — Load balancer (distribute traffic). API gateway (auth, rate limiting). CDN (static assets, images). Cache (Redis — hot data). Database (SQL for relations, NoSQL for flexibility). Message queue (async processing). Object storage (S3 for files/images).
• Database Design Decisions — SQL when: relationships matter, ACID needed, structured data. NoSQL when: flexible schema, horizontal scaling, high write throughput. For mobile: usually SQL backend + local SQLite/Realm on device. Always discuss indexing strategy for read-heavy queries.
• Caching Strategy for Mobile — Three levels: (1) Device cache — images, API responses, user data. (2) CDN — static assets worldwide. (3) Server cache — Redis for hot data. Mobile cache policy: cache-first for reads, optimistic updates for writes, background sync for consistency.
• Real-Time Architecture — Options: polling (simple, wasteful), long polling (better), SSE (server push), WebSockets (bidirectional). For mobile: WebSockets for chat/live features, push notifications for background updates, polling as fallback when WebSocket fails.
• Common Mobile System Design Questions — Design: Instagram feed, WhatsApp messaging, Uber ride matching, Spotify offline mode, Twitter timeline, Google Maps navigation. For each, know: data model, API design, sync strategy, caching approach, and how to handle offline/poor connectivity.
• Drawing the Architecture Diagram — Start with the client (mobile app). Draw the API gateway. Add backend services. Show the database. Mark the cache layers. Use arrows for data flow direction. Label each arrow (REST, WebSocket, gRPC). This visual becomes your discussion anchor.

Code example

# System Design Template & Checklist
# ====================================

# STEP 1: REQUIREMENTS (5 minutes)
\`\`\`
FUNCTIONAL REQUIREMENTS:
- [ ] Core features (list 3-5)
- [ ] User actions (what can users do?)
- [ ] Data flows (what data moves where?)

NON-FUNCTIONAL REQUIREMENTS:
- [ ] Scale: _____ users, _____ DAU
- [ ] Availability: 99.9% uptime? (3 nines = 8.7 hr downtime/year)
- [ ] Latency: < _____ ms for reads, < _____ ms for writes
- [ ] Consistency: Strong or eventual?
- [ ] Storage: _____ GB/TB estimated

MOBILE-SPECIFIC:
- [ ] Offline support needed?
- [ ] Real-time updates needed?
- [ ] Push notifications?
- [ ] Battery/data optimization?
- [ ] Multi-platform (iOS + Android)?
\`\`\`

# STEP 2: HIGH-LEVEL DESIGN (5 minutes)
\`\`\`
┌──────────┐     ┌───────────┐     ┌──────────────┐
│  Mobile  │────▸│    API    │────▸│   Backend    │
│   App    │◂────│  Gateway  │◂────│   Services   │
└──────────┘     └───────────┘     └──────────────┘
     │                │                    │
     │           ┌────┴─────┐         ┌────┴─────┐
     │           │   CDN    │         │   Cache   │
     │           │ (images) │         │  (Redis)  │
     │           └──────────┘         └──────────┘
     │                                     │
┌────┴─────┐                         ┌─────┴──────┐
│  Local   │                         │  Database  │
│   DB     │                         │ (Postgres) │
│ (SQLite) │                         └────────────┘
└──────────┘
\`\`\`

# STEP 3: DEEP DIVE AREAS
\`\`\`
API DESIGN:
  POST /api/v1/posts        → Create post
  GET  /api/v1/feed?page=1  → Get feed (paginated)
  PUT  /api/v1/posts/:id    → Update post
  WS   /ws/notifications    → Real-time updates

DATA MODEL:
  Users:    id, name, email, avatar_url, created_at
  Posts:    id, user_id, content, media_url, created_at
  Feed:     fan-out-on-write for < 10K followers
            fan-out-on-read for celebrities

CACHING STRATEGY:
  Layer 1 — Device:  SQLite for feed, disk cache for images
  Layer 2 — CDN:     All static assets + image thumbnails
  Layer 3 — Redis:   User sessions, feed cache, counters

OFFLINE SYNC:
  - Queue writes locally when offline
  - Sync on reconnection with conflict resolution
  - Last-write-wins for simple fields
  - CRDT for collaborative data (if needed)
\`\`\`

# STEP 4: SCALE & TRADE-OFFS
\`\`\`
BACK-OF-ENVELOPE:
  10M users × 20% DAU = 2M DAU
  2M DAU × 10 reads/day = 20M reads/day ≈ 230 QPS
  2M DAU × 2 writes/day = 4M writes/day ≈ 46 QPS
  Read-heavy → Cache aggressively

TRADE-OFFS DISCUSSED:
  ✓ SQL vs NoSQL → SQL for ACID on payments, NoSQL for feed
  ✓ Push vs Pull → Push for < 10K followers, Pull for celebs
  ✓ Strong vs Eventual consistency → Eventual for feed, Strong for payments
  ✓ WebSocket vs Polling → WS for active, fallback to polling

WHAT I'D IMPROVE WITH MORE TIME:
  - Add monitoring (Prometheus + Grafana)
  - Implement circuit breaker for external services
  - Add A/B testing infrastructure
  - Geographic distribution (multi-region)
\`\`\`

Line-by-line walkthrough

1. 1. Step 1 uses checkboxes — in a real interview, write these on the whiteboard as you discuss them with the interviewer
2. 2. The mobile-specific requirements section is your differentiator — most candidates forget offline support and battery optimization
3. 3. The high-level diagram shows data flow with arrows — label each connection type (REST, WebSocket, etc.)
4. 4. Local DB (SQLite) on the mobile side shows you think about the full stack, not just the server
5. 5. API design uses REST conventions with versioning (/v1/) — mention this shows you think about API evolution
6. 6. The fan-out strategy split (write for normal, read for celebrities) is a classic trade-off interviewers love
7. 7. Three-layer caching (device → CDN → Redis) shows depth of understanding about latency optimization
8. 8. Back-of-envelope calculations prove you can reason about scale — practice these until they're automatic
9. 9. The 'What I'd improve' section shows maturity — no design is perfect, and acknowledging that impresses interviewers

Spot the bug

# System Design: Chat App Architecture
Components:
- Mobile App connects directly to PostgreSQL database
- All messages stored in single database table
- Images stored in database as BLOBs
- No caching layer
- HTTP polling every 500ms for new messages
- Single server handling all traffic

Explain like I'm 5

Fun fact

Hands-on challenge

More resources

• System Design Primer (GitHub)
• Mobile System Design Interview Guide (YouTube)
• Grokking the System Design Interview (Design Gurus)
• Back-of-Envelope Estimation Cheat Sheet (ByteByteGo)