Mobile System Design Introduction

If you've started preparing for a mobile system-design interview, you've probably noticed the shelf is nearly empty. Search "system design interview" and the entire first page is distributed-systems material - sharding, CAP, leader election. Search "mobile system design interview" and you find either generic backend design with an Android label, or surface-level platform tips with no interview walkthrough. The rubric is different: device constraints, not CAP; platform primitives, not queue topology. This catalog fills the gap by working backwards from what the panel actually grades and anchoring every answer in real Android constraints, with worked end-to-end interview walkthroughs.

What is a mobile system-design interview?

A 45-60 minute conversation where the interviewer drops an ambiguous prompt - "design a photo gallery app", "design an image loading library", "design the offline mode for a messenger" - and you drive. There is no single right answer. There is a defensible answer, anchored in real platform constraints (memory budget, battery, lifecycle, OS-imposed limits) and articulated as a sequence of decisions you can justify when pushed. The format is standard at senior+ for mobile-platform roles; this catalog is Android-focused, but the rubric and framework generalize to iOS and cross-platform loops.

A passing answer is graded for how you think, not for which architecture you draw. Two candidates can defend opposite choices ("cache decoded bitmaps" vs "cache encoded bytes") and both pass; one candidate who hand-waves the same choice fails.

What the panel actually grades

Four rubric axes. Every panel rolls their own scorecard; the axes below are the consolidated shape across Google, Meta, Amazon, and Microsoft mobile loops as of 2026.

1. Problem navigation. Turns an ambiguous prompt into a list of testable requirements and calls out what's in scope, what's deferred, and what assumptions are explicit. Treats the prompt as a starting point, not a spec. The red flag is diving into a diagram before clarifying requirements or treating the interviewer's hints as interruptions.

2. Solution design. Reaches for the right platform primitive without being told and names the trade-off when there is one. The red flag is hand-waving "we'd use a queue" without naming the platform-correct primitive, or conflating generic concepts with platform-specific ones.

3. Mobile-platform excellence. Knows the platform's sharp edges and calibrates answers to the SDK level the company actually ships against. The red flag is quoting generic backend engineering ("just add a CDN") when the question is about a device-side problem, or not being able to name where a platform behavior changed.

4. Communication. Thinks out loud, narrates trade-offs, accepts interviewer redirects gracefully, and asks "do you want me to go deeper here or move on?" at natural breakpoints. The red flag is going silent for two minutes mid-decision, arguing when redirected, or not pivoting when the interviewer says "let's assume X is given".

Mobile system design is a different domain from backend system design. There are shared skills: problem navigation - structuring an ambiguous prompt and designing a solution around specific constraints and requirements - and API design - understanding the most efficient way to communicate between the client and server.

Where mobile system design diverges is in how hard it focuses on application architecture that serves a fast, scalable experience on a constrained device: knowing the platform's sharp edges by API level, reasoning about lifecycle, memory, battery, offline behaviour, and network efficiency.

Types of mobile system-design interviews

Every problem on this site follows the same four-phase shape - requirements, surfaces, architecture, deep dives - with the phase times in each problem's badge summing to the interview total. There are (broadly speaking) two types of system design questions.

Application System Design

End-user apps. "Design a photo gallery app", "design a messenger", "design a music player." The product is the system; you own the full device-side stack from the screen down to the wire contract.

We focus on data model and API - defining the domain entities the app works with and the REST / WS / RPC surfaces it speaks to. The architecture follows a fixed six-lane structure - UI, Domain, Data, Local Storage, Network / Push / Sensors, Backend - so every App design in the catalog renders against the same frame and is comparable problem-to-problem. The Backend lane shows only the wire surfaces (REST API, WSS stream, FCM Push); the dispatcher, the geo-index, the internal databases behind those surfaces are out of scope. The mobile candidate's job ends at the wire contract - backend internals are the distributed-systems loop's problem, not this one. The hard parts that win the interview are offline sync, optimistic UI, push handling, background work, and state-driven rendering.

Exemplars: Photo Gallery App, Messenger App, Music Player App.

SDK / Library System Design

Code that runs inside a host app. "Design an image loading library", "design a crash reporter SDK", "design a feature flag SDK." The product is the public API the host app calls; there is no screen of your own.

We focus on API design - how to build software that is used by other developers. The SDK has to be self-contained: it must not crash the host app, must not overload it, has to load fast, and has to be easily integratable in a few lines. The architecture depends on a single test: does the SDK have a genuine execution-context partition - code in context X cannot do Y because of when or where it runs? If yes (crash reporter: the crash-time lane can't allocate or run JVM code), the diagram lanes by execution context, left-to-right as the contexts fire. If no (an HTTP client: one call stack runs end-to-end), the diagram is a single pipeline with each stage annotated by its concern. The hard parts that win the interview are async-signal-safety, never-throw contracts at the SDK boundary, binary size discipline, init-time setup, and thread-safety across caller contexts.

The durability artifact that bridges two lifetimes - the .crash file, the analytics WAL, the last-known-good cache - goes on the boundary between the lanes it connects, not buried inside one lane. That artifact is the design; tucking it inside a single lane hides the essential handoff.

Exemplars: Crash Reporter SDK, Image Loading Library, Feature Flag SDK.

Let's dive in

The catalog is organized for the most effective learning path. If you're coming fresh, or haven't done any mobile system design since before the Jetpack Compose era, start with the Mobile Core Concepts overview for the map. If you already have the core knowledge, jump straight into a problem and read it end-to-end, detect your weak points, and jump back to the core concepts. The goal is simple: walk into your mobile system-design interview ready.