How do you approach a mobile system design question: what do you clarify, in what order do you design, and what separates a senior from a staff answer?

26.1.1 · L5 · Interview

Predict first

Which opening is strongest for “design a photo-sharing app”?

// A: draw the server, the CDN and the database first
// B: ask about users, core journeys, scale and non-goals, then state the invariants (no lost uploads, private photos stay private)
// C: list every framework you would use

Mental model. Designing a feature is like planning a trip. You decide the destination and the things that must not go wrong first (passport, tickets), then the route, and only then pack the bags.

Use the same loop every time, and say it out loud so the interviewer can steer. 1) Clarify the product and scope: who the users are, the two or three core journeys, platforms, and the scale that matters (users, items, message rates, device storage, network quality); write down non-goals. 2) Pin the invariants: what must never happen (a double charge, a lost message, showing another user’s data) and what may be stale. 3) Define the contract: the API or events between client and server (identifiers, pagination, versioning, error shape), because the client design follows from it. 4) Choose the data model and the source of truth: usually a local database that the UI observes, with the network feeding it (Q331, Q337). 5) Sketch the client architecture in layers (UI, state, domain, data) and where concurrency lives. 6) Design the hard flows: sync and conflicts (Q340), offline and retries (Q324), background work (Q224), media and caching (Q327, Q338). 7) Failure modes and degradation: what the user sees when each dependency is slow, down or wrong. 8) Cross-cutting: security and privacy, accessibility and localisation, battery and memory, analytics and experiments. 9) Rollout and operations: flags, staged release, metrics and alerts (Q486, Q432).

Time-box it: spend the first minutes on requirements, most of the time on two or three hard parts rather than every box, and state trade-offs as you decide (“local database as the source of truth costs migrations and gives instant, offline-capable UI”). The difference in level shows in the quality of the questions and the trade-offs. A senior answer is correct and complete for the feature. A staff answer also names the alternatives and why they were rejected, ties choices to cost, team structure and operations (who owns this, how it is observed, how it is rolled back), identifies the riskiest assumption and how to test it cheaply first, and plans the migration or rollout, not only the end state. Avoid two failure modes: designing only the server, and drawing the client as one box labelled “app”.

Requirements and invariants justify every later decision; boxes and frameworks without them cannot be defended.

	Question to answer	Artefact
Scope	who and what, at what scale	journeys and non-goals
Contract	what do client and server say to each other	API or event shapes, ids, pagination
State	where does truth live, who may change it	local database and sync rules
Failure	what does the user see when it breaks	degradation table, retry and offline rules
Operations	how is it shipped, observed and undone	flags, metrics, rollout plan

Common traps

Jumping straight to boxes and technology names. Without requirements and invariants you cannot justify any choice.
Describing only the happy path. Offline, retries, partial failure and old app versions are where mobile design is judged.

They might follow up with

What do you say first? Users, core journeys, scale and non-goals, then the invariants.
How do you show staff-level thinking? Alternatives and trade-offs, ownership and operations, the riskiest assumption, and a rollout plan.

How do you approach a mobile system design question: what do you clarify, in what order do you design, and what separates a senior from a staff answer?

Predict first

Common traps

They might follow up with

Related questions