Section 6: A Map That Lags, a Hold That Decides - High-Level Architecture
Executive Summary: This section assembles the API from Section 4 and the data model from Section 5 into one architecture. Three million fans meet the edge, not the origin. A waiting room lets about 67 shoppers a second through, an API gateway checks their admission tokens, and only the inventory service writes seats, in one strongly consistent partition per show. Everything a fan reads is cached and may lag by seconds. We defend the seat-map bitmap against its rivals, then walk Jordan through every box.
Drawing the Board
The interviewer slides the marker across: "You have the contracts and the tables. Draw the system."
You: "One rule shapes the drawing: reads can be stale, the hold cannot. So there are two paths. The read path serves event pages, seat layouts and a 7.5 KB availability bitmap from caches. The write path takes a hold or a checkout into one service that owns the truth for that show. The paths touch in one place: the inventory change stream that refreshes the bitmap. And in front of both sits a waiting room, so the backend sees 20,000 shoppers, not three million fans."
| Component | Job | Consistency | The number that sizes it |
|---|---|---|---|
| CDN and edge workers | Event pages, static seat layouts, waiting-room status; issue and validate queue tokens | Cached | 100,000 status polls/s during the on-sale |
| Waiting-room controller | Holds the signing keys, aggregates edge bucket counts into the arrival histogram, moves the admission watermark | Eventual (seconds) | 33,000 joins/s, about 67 admissions/s |
| API gateway | Checks admission tokens on hold calls, forwards the account id | Stateless | 20,000 requests/s design load |
| Catalog and search | Events, venues, search, on read replicas and a cache | Eventual | About 400 page views/s on a normal day |
| Availability service | Builds one bitmap per show from the change stream, about every second | Eventual: served bitmap at most 2 s behind the database | 10,000 requests/s × 7.5 KB = 75 MB/s |
| Inventory service | Holds, releases, held-to-sold, the 4-ticket limit; the only writer of seat state | Strong | 200 holds/s average, about 1,000 hold attempts/s peak on one show |
| Checkout and order service | Payment saga with an idempotency key per checkout | Strong | Checkout p99 at most 3 s |
| Ticketing and notifications | Issues tickets with rotating barcodes, sends confirmations | Strong for tickets, async for messages | 60,000 tickets for E-7781 |
The waiting room engages only for hot on-sales. On a normal day the whole platform takes about 6 orders a second, and requests pass straight from the edge to the gateway.
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