Mobile System Design Interview: A Framework, Platform Limits and a Worked Example

How the mobile round differs from backend system design

Both rounds test structured thinking under ambiguity, and both start with requirements. The difference is where the hard constraints live. A backend answer is shaped by request volume and data size. A mobile answer is shaped by a single device that loses its network in an elevator, is suspended when the user switches apps, and may run a version of your code released a year ago.

That changes what counts as a deep dive: sharding and consensus rarely come up, while pagination, sync, images, push and lifecycle do. You still need enough backend literacy to specify the API you depend on, and to say what you would require from the server to keep the client simple.

• How to prepare for a system design interview

A twelve-step framework with a 45-minute budget

The twelve steps: requirements, API contract, client architecture, data layer, offline and sync, pagination, caching and images, push, background-work limits, errors and retries, observability, release. That is too many to give equal time, so the table groups them into six phases; decide in advance where you will go deep. The budget uses 43 minutes and leaves two for your questions.

Say the plan out loud in the first minute. It shows you will reach the mobile-specific topics, and it lets the interviewer redirect you early if they want most of the time on sync and none on release. Draw one diagram and keep extending it; the layered diagram in the worked example is a reasonable default.

Platform limits that shape the design (Apple and Android docs)

Mobile designs are credible when each choice is tied to a documented limit. The table collects the limits this guide relies on, as written in Apple's and Google's developer documentation on November 14, 2026. They change between OS releases, so recheck them before an interview and say “as documented” instead of quoting numbers as permanent.

Three consequences follow. First, you cannot count on an open socket or a timer once the app is in the background, so background freshness comes from push plus short, system-scheduled work. Second, a push payload is capped at 4,096 bytes on both platforms, and pushes that only wake the app are low priority and may be throttled on both, so push can signal a change but cannot be the channel your data depends on. Third, work that must finish, such as an upload, belongs to an API built to outlive your process: a background URLSession on iOS, WorkManager on Android.

• Apple Developer: Choosing Background Strategies for Your App
• Apple Developer: Extending your app's background execution time
• Apple Developer: BGProcessingTask
• Apple Developer: Generating a remote notification
• Apple Developer: Pushing background updates to your App
• Apple Developer: Downloading files in the background
• App Store Connect Help: Release a version update in phases
• Android Developers: Background tasks overview
• Android Developers: Define work requests (WorkManager)
• Android Developers: Optimize for Doze and App Standby
• Firebase Cloud Messaging: message types and payload limit
• Play Console Help: Release app updates with staged rollouts

Worked example: an offline-capable feed client

Prompt: design the mobile client for a social feed. Suppose clarification yields these requirements: the feed opens instantly with the last content seen, even with no network; the user can scroll back through older posts; a post written offline is sent later; new posts appear without a manual refresh while the app is open; and images must not burn through a cellular data plan.

The architecture follows Android's app-architecture guide, and the same shape works on iOS: a UI layer renders state and sends events; a state holder (a ViewModel on Android, an observable model on iOS) turns repository streams into screen state; repositories hide where data comes from. Android's offline-first guidance supplies the central rule: the local database is the source of truth, the UI reads only from it, and the network exists to update it. That rule alone answers the instant-open and offline-reading requirements.

The contract below is what the client needs from the server. Cursor pagination keeps scrolling stable while new posts arrive. A changes endpoint returns only upserts and deletions since a sync token, so a refresh is cheap. The write carries an idempotency key and a client-generated id, so a retried request cannot create a duplicate and the local draft can be matched to the server's record. The background push carries no feed content, only a signal to sync.

One detail of the diagram matters in follow-up questions: the sync worker has no network path of its own. The repository enqueues pending writes; when the worker runs, after a push, on a schedule or when connectivity returns, it calls back into the repository, which owns the HTTPS client and the database. Retry, idempotency and conflict handling stay in one place.

# Read: cursor-paginated and cacheable
GET /v1/feed?limit=20&cursor=<opaque>
200 OK
ETag: "f3a9"
{ "items": [ { "id": "p_812", "version": 7, "text": "...",
               "image": { "url": "...", "w": 1080, "h": 1350 },
               "created_at": "2026-11-14T09:30:00Z" } ],
  "next_cursor": "<opaque>", "poll_after_s": 60 }

# Refresh: only what changed since the last sync
GET /v1/feed/changes?since=<sync_token>
200 OK
{ "upserts": [ ... ], "deleted_ids": [ ... ], "sync_token": "<opaque>" }

# Write: safe to retry
POST /v1/posts
Idempotency-Key: <uuid created once per user action, stored with the queued write>
{ "client_id": "local-42", "text": "..." }
201 Created
{ "id": "p_901", "client_id": "local-42", "version": 1 }

# Background push: a signal to sync, never the only copy of the data
{ "type": "feed_changed" }

• Android Developers: Guide to app architecture
• Android Developers: Build an offline-first app
• Cursor vs offset pagination
• API idempotency keys and safe retries

Offline, sync, pagination and images: the trade-offs

Reads: the repository exposes an observable query on the local database, so a screen re-renders whenever a sync writes new rows. Android's Paging library supports this layering through RemoteMediator, which pages network data into a local database cache. Writes: Android's guidance names three strategies. Online-only writes fit operations that must happen online in near real time, such as a bank transfer. Queued writes fit data that is not time sensitive, such as analytics events. Lazy writes save locally first and then queue the network call; the guide calls this the correct choice when the data is critical to the app, as content the user typed is.

Sync can be pull-based, fetching when the user navigates to a screen, or push-based, where the server signals that data is stale and the client fetches only what changed. The same guide suggests a hybrid for social apps: pull for a fast-changing feed, push-based sync for slow-changing data such as the user's profile. Conflicts need a rule. Last write wins is the common starting point and loses data when two devices edit the same item, so say when you would move to versions checked by the server.

Images dominate bytes. Ask the server for variants sized to the view, keep a memory cache for decoded bitmaps and a disk cache for files, and cancel requests when a cell scrolls away. On iOS, URLCache provides a combined in-memory and on-disk response cache, and Apple notes that the disk part can be purged when the system is low on space, so treat it as a cache and not as storage. For JSON, conditional requests help: with an ETag, an unchanged resource comes back as 304 Not Modified with no body.

• Android Developers: Build an offline-first app
• Android Developers: Paging library overview
• Apple Developer: URLCache
• RFC 9110: HTTP Semantics (conditional requests, 304 Not Modified)
• REST vs GraphQL vs gRPC

Push, background work, errors and retries

Treat push as a doorbell. A visible notification tells the user; a background notification tells the app to sync. Apple's documentation is blunt about the second kind: the system treats it as low priority, may throttle it, holds only the newest one, and gives the app 30 seconds once it arrives. So the design must be correct with zero pushes delivered: sync when the app comes to the foreground, plus scheduled refresh where the platform grants it.

On Android, Doze suspends network access between maintenance windows, and Google's guidance is to use FCM. That guidance seems to contradict the doorbell rule, so read it closely. For a notification the user must see right away, it says to put enough information in the payload that no further network access is needed. Messages that show no notification and only trigger a sync are, in the same document, intentionally low priority and may be delayed or throttled. The two fit together: a push may carry what its own notification displays, while the app's data still arrives through sync.

Every network call needs three answers: is it safe to retry, how long to wait, and what the user sees. Reads are safe; writes become safe with an idempotency key. Wait with exponential backoff and jitter so that thousands of clients do not retry in step; 1, 2, 4, 8, 16 and 32 seconds, capped at 60, is a reasonable foreground schedule. Show the queued state in the UI, such as a post marked as sending, and separate retryable failures (timeouts, 5xx responses) from terminal ones (a validation error) that must go back to the user.

• Foreground: fetch on open and on pull-to-refresh; poll or hold a socket only while visible.
• Killed mid-write: the queue lives in the database, so the next launch resumes it.

• Apple Developer: Pushing background updates to your App
• Android Developers: Optimize for Doze and App Standby
• Android Developers: Define work requests (WorkManager)

Observability and release: the steps candidates skip

You cannot attach a debugger to a user's phone, so the client has to report on itself. Name a few signals: crash rate; API error rate and latency measured on the device; sync queue depth and the age of the oldest pending write; cold-start time. On Android add the ANR rate; the system reports an ANR when an input event gets no response within 5 seconds. Split every signal by app and OS version, and send telemetry in batches through the queued-write path.

Release is where mobile differs most from backend. Apple's phased release reaches users with automatic updates over seven days and can be paused for up to 30 days in total; Google Play's staged rollout goes to a percentage of users that you raise yourself and can halt. Neither removes a bad build from phones that already have it. So make behavior adjustable from the server: feature flags fetched at launch, a kill switch for risky features, a minimum-supported-version check, and an API that stays backward compatible with every version still in use.

• App Store Connect Help: Release a version update in phases
• Play Console Help: Release app updates with staged rollouts
• Android Developers: ANRs

Common mistakes, and how to practice

Practice on prompts that stress different parts of the framework: a feed (pagination and images), a chat (ordering, delivery state and push), photo upload (background transfers and retries), offline notes (conflicts), and live location for a delivery (battery and update frequency). Time yourself at 45 minutes, draw the same layered diagram, and say which documented limit drives each decision. The question banks below cover the platform knowledge that the deep dives draw on.

• Designing the backend for thirty minutes and the app for ten.
• Letting screens call the network directly, with no local source of truth.
• Treating push as the data channel, or assuming background pushes always arrive.
• Assuming background code keeps running: timers, sockets and loops stop when the app is suspended.
• Retrying writes without idempotency, or retrying forever without backoff.
• Ignoring old app versions: every API change must work with clients you cannot update.
• No answer for a process killed mid-operation.
• Listing libraries instead of the property each one provides.

• 52 system design interview questions
• iOS GCD and Swift Concurrency interview questions
• Android coroutines and Flow interview questions
• iOS developer interview track
• Android developer interview track

Quick answers

Frequently asked questions