Mobile System Design Is Not Backend System Design

A lot of engineers prepare for mobile system design interviews by memorizing backend system design templates. They learn how to talk about databases, queues, caches, sharding, load balancers and service boundaries. That knowledge is useful, but it is not enough for a senior iOS interview.

A senior mobile interview is usually not asking you to redesign Twitter's backend with an iPhone screen attached. It is asking whether you understand the system that exists between the server and the user. That system includes the app process, local persistence, memory pressure, background execution, network failure, platform APIs, push delivery, release risk and the user's trust.

If your answer jumps straight to microservices, you may sound technically fluent while missing the part the interviewer is actually testing.

A backend system design answer usually starts with services, databases, queues and load balancers. A mobile system design answer starts somewhere less comfortable: an unreliable device in somebody's pocket.

The app can be killed. The network can disappear. Storage can fill up. The user can perform actions offline, then expect the app to reconcile them later without losing trust. A screen can render with stale data, duplicate data, partial data or no data. A task can be cancelled because the user scrolled away. A background job can be delayed or denied by the operating system.

That changes the order of the answer. You still need to talk about APIs and backend contracts, but only after you explain state ownership, latency perception, local persistence, sync boundaries, app lifecycle, memory pressure, battery, privacy and release safety.

A mobile app is not a thin client. It is a distributed node with a UI, cache, persistence layer, sync engine, background task model, notification surface, feature flags, analytics, crash reporting and platform constraints. The system succeeds or fails on the device before the user ever thinks about the backend.

Most mobile system failures are state failures. A feed shows stale data. A sync engine overwrites the wrong value. A cache keeps the app fast until it quietly becomes wrong. A button looks enabled even though the operation already failed in the background.

For most mobile features, state exists in several layers at once: server state, local persisted state, in-memory state, UI state, optimistic state and derived state. Bugs happen when those layers are unnamed. Senior design means naming them, assigning ownership and describing how they converge after failure.

Take a feed. A weak answer says: fetch posts, paginate results, cache images. A stronger answer asks: what is the source of truth when the user is offline? How long can cached feed data be trusted? What happens when the server sends an updated item that conflicts with a local optimistic action? If the user likes a post offline, where is that pending mutation stored? How do we avoid showing duplicate items across pages? How do we cancel image work when cells disappear? How do we measure whether the feed is healthy in production?

Caching answers the question: what can I show when I cannot reach the server? Offline-first answers a harder question: what can the user safely do when I cannot reach the server?

In an interview, say exactly what offline means for the feature. Can the user read existing data? Create new data? Edit existing data? Delete data? Queue actions? See pending status? Retry manually? Abandon failed work?

Then describe the pending operation model. Store mutations durably with stable IDs, timestamps, retry counts and idempotency keys. Make the UI show pending, failed and synced states. Make retries safe. Make conflicts visible when automatic resolution would damage trust.

Conflict policy should match the domain. Last-write-wins may be acceptable for low-value preferences. Server-wins may be right for permissioned data. Manual merge may be necessary for collaborative documents. Operation logs can preserve intent better than overwriting whole records.

Backend services are usually designed to keep running. Mobile apps are designed to be interrupted. The user can background the app. The operating system can suspend it. Memory pressure can terminate it. A background task can be given a tiny execution window or no execution window at all.

That means important work needs a durable representation. If the app must eventually upload a draft, sync a note or complete a checkout step, that work cannot exist only as an in-memory Task. It needs to be stored, resumed and reconciled.

A vague answer says: we retry in the background. A senior answer says: we persist pending operations locally, include idempotency keys, resume sync on launch and foreground transitions, use platform background APIs where appropriate, handle expiration, and surface unresolved failures to the user instead of silently dropping work.

They want constraints before components. They want tradeoffs before patterns. They want to know whether you can design for battery, memory, app lifecycle, offline work, rollout risk and observability.

A good mobile system design answer says: here is the user promise, here are the device constraints, here is the state model, here is the data flow, here is what works offline, here is how failures recover, here is how the UI stays fast, and here is how we will know this works in production.

Backend architecture still matters. APIs, databases, queues and services matter. But in mobile system design, the phone is not just a client. It is the environment where the system is judged.