</> MAANG.io
system design · 301

Advanced

Master system design interviews with scalable architecture patterns, distributed systems, and real-world design challenges.

0/480 solved 0% complete

Section 1: The Store That Is Mostly a Delivery Truck - Problem Understanding & Clarifications

Executive Summary: This section opens a Staff/Principal interview on the mobile app store. We decompose the prompt four ways, finding two customers plus the platform itself. We name the two ways strong candidates fail it: the Catalog Clerk and the Push Maximalist. Then we run five clarifying exchanges, each of which deletes a category of work. The prompt ends as committed assumptions, each with the condition that would reverse it, plus a running example the next twelve sections follow: Priya's Pixel 7 in Pune, and Trailhead Maps 4.3.0.

The interviewer reads you one sentence:

"Design a mobile app store, like Google Play or Apple's App Store. Developers upload their apps; users on billions of phones discover them, install them, and keep them updated. Walk me through the system end to end."

The trap is the word store. It summons a catalog: product pages, search, a buy button. Those are the easy part. The last three words matter more: keep them updated. Every app on every phone gets a new version every few weeks, and something has to notice, pick the right bytes and deliver them. Under the shop window sits a software-distribution system for billions of devices, and one that can put code on all of them is the most valuable supply-chain target on earth.

The Catalog Clerk. You design an e-commerce site: an apps table, search, a cart, checkout, and one box labelled "CDN" drawn in the last five minutes. You never ask how one binary fits a thousand device models, notice that updates dwarf installs, or ask how a bad release gets stopped. Signal recorded: modelled the shop window, not the delivery truck.

The Push Maximalist. You hear "keep them updated" and build a server-side queue of pending updates for every device, plus a push to each one on every release. When a popular app ships, hundreds of millions of rows get rewritten and hundreds of millions of phones download at once. Signal recorded: never asked who should hold the state.

Key Insight: The phone already knows what is installed on it. The Clerk forgets the phone after the first install; the Maximalist ignores what it knows. Most of the good design here comes from letting the device ask and keeping the server's answer cheap.

Decomposing the Prompt Four Ways

Map the territory before asking anything.

  • What it does. Verbs: publish, discover, install, update, buy, rate. Only install, update and buy move serious bytes or money.
  • Who uses it. Two customers and a third party. Developers upload releases, edit listings and decide how fast a release spreads. Users browse, install, pay and expect updates to just happen. The platform scans, reviews, signs and sometimes removes apps, and answers to regulators.
  • Why it exists. Trusted distribution. A user installs an app from a stranger in Lisbon because the store vouches that the bytes are the developer's, unaltered. Revenue rides on that trust.
  • How it is reached. The store app, a background updater nobody watches, a developer console and a publishing API called from developers' CI pipelines.

Problem unpacked: designing an app store breaks into what, who (developers, users, platform), why and how, with bytes and money moving only in install, update and buy

Sign in to continue reading

The rest of this lesson is available with a free account. Signing in with Google or Microsoft is free.

Sign in to read the full lesson

Sign in to MAANG.io

Use your Google or Microsoft account — no password to remember.

Continue with Google Continue with Microsoft

Please accept the terms above to continue.