Mobile system design

What changes when the client is a phone: unreliable networks, battery and data limits, offline-first storage, sync, API design for mobile, image and media sizing, push notifications, app versions that never update, background work limits, startup performance and release processes.

Reading is half of it. See this used in a real interview: walk through Design Instagram →

Many system design interviews, and all mobile-specific ones, expect you to consider the client. A phone is not a small browser: its network drops in tunnels, it has a battery and often a data cap, the operating system kills background work, and users run app versions from two years ago. Designs that ignore this produce apps that feel slow, drain batteries and break on old versions. This guide covers what to say about the client side.

Unreliable networks

• Expect high latency (hundreds of milliseconds on cellular), packet loss and sudden disconnects.
• Minimise round trips: one request per screen, aggregated by a backend for frontend or GraphQL. See API gateways.
• Use timeouts and retries with backoff, with idempotency keys so retried writes are safe. See distributed transactions and idempotency.
• Compress payloads; prefer compact formats for heavy traffic.
• Use HTTP/2 or HTTP/3 to reuse connections; QUIC handles network changes (Wi-Fi to cellular) better.

Offline first

Store data locally (SQLite or a mobile database) and render from it, so the app opens instantly and works without a network. Queue writes in an outbox and sync when connected, with conflict rules per data type. Show optimistic UI for user actions (the message appears as sent, with a pending marker). See offline-first apps and sync.

Sync and freshness

• Fetch deltas since a cursor rather than full lists. See pagination.
• Use a persistent connection while the app is in the foreground for real-time updates, and push notifications when it is not. See WebSockets vs SSE vs long polling.
• Prefetch likely next content on Wi-Fi and while charging.

Battery and data

• Batch network requests; radios stay in a high-power state for seconds after each request, so many small requests cost much more than one larger one.
• Avoid frequent polling and wake-ups; rely on push.
• Respect low-data and low-power modes; defer large downloads to Wi-Fi.
• Heartbeat intervals for persistent connections balanced against battery and carrier timeouts. See presence and connection management.

Images and media

• Request images sized for the device and screen density, in modern formats, from a CDN. See media uploads and processing.
• Show low-resolution placeholders or blur hashes while loading.
• Upload in chunks, resumable, in the background where the OS allows, with compression on the device before upload.
• Cache media on disk with size limits and eviction.

See Design Instagram.

Push notifications

Push wakes users and apps: new messages, order updates, matches. Tokens per device, preferences, quiet hours and collapse keys to avoid spam. Silent pushes are throttled by the OS, so never depend on them for correctness. See push notifications and Design WhatsApp.

Background work

iOS and Android restrict background execution heavily: tasks run when the system allows, for limited time. Design sync to be incremental and resumable, use platform background task and upload APIs, and do important work when the app is in the foreground. Location tracking (delivery couriers, ride drivers) uses dedicated location APIs with battery-aware accuracy. See Design DoorDash.

Old app versions

Users update slowly, and some never do. The backend must:

• Keep old API shapes working for months or years; make changes additive. See schema evolution and serialization.
• Track usage by app version and deprecate deliberately.
• Have a forced upgrade mechanism for security issues or truly breaking changes.
• Use server-driven configuration and feature flags to change behaviour without a release. See feature flags and A/B testing.

Some apps go further with server-driven UI: the server describes screens, so layouts change without app updates.

Releases

App store review delays and staged rollouts mean a bad release cannot be rolled back instantly. Release gradually (1 %, 10 %, 100 %), monitor crash rates and key metrics per version, and keep risky features behind flags that can be turned off remotely. See deployment strategies.

Performance

Measure cold start time, time to first content, scroll smoothness (dropped frames), crash-free sessions and network error rates per version and device class. Lazy-load features, avoid heavy work on the main thread, and cache the first screen's data for instant display.

Security

Store tokens in the platform's secure storage (Keychain, Keystore), use certificate pinning for high-risk apps, never embed secrets in the app binary (it can be decompiled), and validate everything on the server. See security and auth.

In the interview

When the product is mobile-first: local database and outbox for offline use, delta sync by cursor, a WebSocket in the foreground and push in the background, device-sized images from a CDN, resumable background uploads, idempotent retries, backward-compatible APIs with version tracking, and feature flags for remote control. See Design Tinder for a mobile-heavy example.

Checklist

• Few round trips, retries with idempotency keys, compressed payloads.
• Local storage, optimistic UI, outbox sync and conflict rules.
• Persistent connection in foreground; push in background.
• Batched networking for battery and data.
• Device-sized images, chunked resumable uploads, disk caches.
• Backward-compatible APIs, version tracking, forced upgrades, remote config.
• Staged releases with crash monitoring and kill switches.