Mobile system design cheat sheet

The 10 Mobile system design interview answers in 30 seconds each, plus quick facts. Printable, free.

One page per topic: print it or save it as PDF from your browser's print menu. Practise these questions

Rules of thumb

  • Local database first; the network fills it.
  • Client IDs and idempotency keys make retries safe.
  • Socket in foreground, push in background.
  • Halt the rollout first, debug second.
  • Safe defaults for every remote flag.

Designing an offline-first app

Make the local database the single source of truth: the UI observes Room, and the network only updates the database. User changes are written locally first with a 'pending' state and queued for sync with WorkManager under a network constraint. On sync, send changes with IDs and versions so the server can detect conflicts, then pull and merge server changes.

Designing a social feed

Fetch pages with cursor-based pagination through Paging 3 and a RemoteMediator that stores pages in Room, so the feed opens instantly from cache. Render with a LazyColumn using stable keys and content types. Load images with a library that downsamples and caches. Likes update optimistically in the database, then sync; roll back on failure. Pull-to-refresh replaces the first page.

Designing a chat app

Keep a persistent connection, such as a WebSocket, while the app is in the foreground, and rely on FCM high-priority messages when it isn't. Store conversations and messages in Room and render from there. Send messages with a client ID and 'sending' state, retry through WorkManager, and mark them sent on server ack. Order by server sequence numbers, and sync missed messages on reconnect.

Designing an image loading library

A request goes through a pipeline: check a memory cache (an LRU of decoded bitmaps sized to a fraction of the app's heap), then a disk cache of encoded bytes, then the network. Decode off the main thread, downsampled to the target view size, deduplicate identical in-flight requests, and cancel requests when the view or composable leaves the screen.

Designing reliable uploads

Copy the photo into app storage and record an upload row in Room. Enqueue unique WorkManager work with a network constraint (unmetered if large), with exponential backoff. Upload in resumable chunks, or with a server-provided upload URL, so retries continue where they stopped. Show progress through WorkInfo, and use a foreground (long-running) worker with a notification for big uploads.

Handling a crash spike after release

First limit the damage: halt the staged rollout in Play Console and turn off the feature with a remote flag if possible. Then find the cause: group crashes in Crashlytics or Android vitals by version, device and OS, read de-obfuscated stack traces, and compare with the previous release. Fix, test, and roll out a patch gradually. Afterwards, write a blameless review and add a test or alert.

Feature flags and staged rollouts

Ship code dark behind a remote feature flag (Firebase Remote Config or your own service), and release the app through a Play staged rollout. Turn the flag on for staff, then a small percentage, watching crash rate, ANRs and business metrics, and expand. Keep a kill switch. Cache flag values with safe defaults so the app works offline, and remove flags once a feature is fully launched.

Designing subscriptions with Play Billing

Use the Play Billing Library to show products and launch purchases, but treat your server as the source of truth. Send the purchase token to your backend, verify it with the Google Play Developer API, grant access, and acknowledge the purchase within three days or Google refunds it. Listen to Real-time Developer Notifications for renewals, cancellations and grace periods.

Designing location tracking

Start a foreground service with the location type and a visible notification when the user taps Start. Request location from the Fused Location Provider with a suitable interval and priority. Write points to Room in batches so a crash loses little. Ask for fine location while in use; background location is a separate, harder permission you usually don't need, because the foreground service counts as in use.

Designing an analytics or logging SDK

Keep it tiny and safe: a public API that never throws or blocks, events written to a small on-disk queue, and batched uploads with WorkManager under network constraints, with backoff and size limits. Initialise lazily, avoid heavy dependencies, and expose consent controls so nothing is sent before the user agrees. Version the event schema and drop old events when the queue is full.

Quick facts

Crash threshold
Google Play's bad-behaviour threshold for user-perceived crash rate is 1.09% overall.
ANR threshold
Google Play's bad-behaviour threshold for user-perceived ANR rate is 0.47% overall.
Purchase acknowledgement
Play refunds purchases that aren't acknowledged within three days.