Design a Mobile App Store (Google Play, App Store)

The prompt sounds like a shop with icons: "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."

Most candidates hear "store" and draw a store: a product catalog, a search box, a details page, a buy button, and a box labelled "CDN" somewhere near the end. It is a reasonable instinct aimed at the wrong half of the problem. An app store is first a software-distribution system and only second a shop. The catalog it browses is two million apps, small enough that its whole update index fits in the memory of one server. What does not fit anywhere comfortable is the traffic that happens after the install: three billion devices, forty apps each, every one of them asking several times a day whether anything new has shipped, and then downloading it.

The arithmetic makes the point for you. New installs run at about 300 million a day. Updates run at about 4 billion a day, thirteen times as many, and even after shrinking each update to a 10 MB delta they are still 77% of the 52 petabytes the store sends every day. Update checks arrive at 420,000 a second at peak. A candidate who does that napkin math in the first fifteen minutes designs a delivery system with a storefront attached. A candidate who skips it designs a storefront and then discovers, under questioning, that the delivery truck was the product.

The Trap Built Into a Familiar Shape

Two failures show up in this question again and again:

• The Catalog Clerk: designs Amazon-with-icons, with a product table, search, cart and checkout, and treats delivery as one box at the end. Never discovers that updates dominate, that one binary does not fit every device, or that a release needs to be staged and stoppable. Signal: modelled the shop window, not the delivery truck.
• The Push Maximalist: hears "billions of devices, keep them updated" and builds a server-side queue of pending updates for every device, plus a push notification to every device on every release. A popular app's release now rewrites hundreds of millions of rows and triggers a synchronized download stampede. Signal: never asked who should hold the state.

The passing performance notices three things early: the device already knows what it has installed, so the device should ask and the server should answer from a small in-memory index; one bundle should become many device-specific files, so nobody downloads code for a chip they don't have; and a store that can push code to three billion phones is the most valuable supply-chain target on earth, so every release is signed end to end, starts small by default, and can be halted.