Section 7: One Document, Many Phones - Deep Dive: The Storefront & Search

Executive Summary: The storefront is the only part users see and the cheapest to make fast, so it goes first and stays short. Each details page is one ~5 KB document per (package, locale), built from the change feed and cached at the edge for 5 minutes, so ~90% hits cut 174,000 views a second to 17,400 origin builds. Compatibility is a thin per-request check on top of that shared document, never part of the cache key. Search is a small inverted index replicated whole per region, with compatibility filtered inside retrieval and ~1,000 candidates ranked down to 50. Ratings arrive as pre-aggregated histograms.

Section 6 ended with the marker in the candidate's hand. "Where do you want to go deeper?"

You: "Storefront first, because it's what users see and the wins are cheap. About ten minutes. Then delivery, where the load is: 420,000 checks a second and 14.4 Tbps. That's Section 8, and it gets most of the time. Publishing last."

Interviewer: "Why start with the easy one?"

You: "To show why it stays easy. The catalog is 80 GB of listings. That's a caching problem, not a database problem."

The Details Page: One Document per App and Locale

Priya opens Trailhead Maps on her Pixel 7. Her phone sends GET /v1/apps/com.trailhead.maps?locale=hi-IN with the X-Device-Profile header from Section 4. Here is the whole path:

The document builder listens to the change feed. On a listing edit, release change, takedown or rating update, it rewrites the affected (package, locale) documents in a key-value store. Each holds the localized text, screenshot URLs, the rating histogram, a per-country availability and price block, and a compact requirements block (minSdk, ABIs, required features). 2 million apps × 8 locales = 16 million documents, about 80 GB, which fits in memory on a KV cluster in every region.

The arithmetic follows from Section 3:

Interviewer: "Why not just render the page from the catalog database? It's already strongly consistent."

You: "I rejected that. The catalog DB holds the release state machine publishing commits against, and 174,000 reads a second would put browsing load on the store whose correctness matters most. The storefront tolerates 5 minutes of staleness and runs at 99.95%, not 99.99%, so it reads a derived copy. If the KV or API goes down, the edge serves stale documents (stale-if-error), and update delivery never notices."