Section 6: Drawn to Scale - High-Level Architecture & Component Design
Executive Summary: This section assembles the whole system: clients talking to a thin API layer, behind which an order service owns transactions and the payment client, a menu service publishes versioned documents to a CDN, an availability service runs the 86 board and pushes invalidations, a kitchen display service holds one socket per store, and a notification sender fires READY pushes — all over one relational database (D5), with the payment provider as the only external dependency. We give every component exactly one number from Section 3's ledger, then run two complete journeys through the diagram: Maya's order from 12:10 to 12:11, and Marco's 86 of avocado at 12:35 propagating to every open cart inside thirty seconds. We finish with the review that separates Staff candidates from box-drawers: defending the components that are deliberately not there.
The interviewer hands you the marker: "Draw it." This is the moment the machinery summons you. Every architecture you've admired — the event bus, the service mesh, the inventory microservice with its own datastore — is pulling at your hand. Resist, because Section 3 already measured this building: 3.5 orders per second chain-wide, 35 at national peak, 600 MB of new data a day. The diagram must obey the arithmetic. What earns boxes here is not throughput but jobs: the distinct clocks and trust boundaries Sections 4 and 5 uncovered. Menus change weekly; availability changes hourly; orders change by the second; money changes hands exactly once. Each of those gets a component. Nothing else does.
The Whole System on One Whiteboard
Ten boxes, one database, one external dependency. Each component carries one number from the ledger — the number that justifies its existence and sizes it:
| Component | The job it refuses to share | Its one ledger number |
|---|---|---|
| API layer | Auth, routing, the three surfaces of Section 4 | 35 orders/s national peak |
| Order service | The order transaction, the PSP client, the D9 state machine | 3.5 orders/s chain-wide average |
| Menu service | Publishes immutable versioned menu docs to the CDN (D6) | 30 KB per doc, ~700 menu loads/s at peak — all edge-served |
| Availability service | The 86 board: toggles, overlay versions, push invalidation | ≤ 30 s cascade budget on a ~1 KB overlay |
| Kitchen display service | Per-store prep queue, ordered by promise time | One socket per store — 500 total, not 500,000 |
| Notification sender | READY pushes and SMS, best-effort | ~300K notifications/day — a background trickle |
| Database | Everything in Section 5's schema, transactionally | 600 MB/day ≈ 220 GB/year |
| Payment provider | Authorization and capture; external, idempotent | ~500 ms–1 s per auth — the dominant checkout latency |
Notice the asymmetry the two-documents decision (D6) buys us: the read-heavy path (6M menu loads a day) never touches a service at all — it's a CDN serving a static versioned document plus a tiny overlay. The write path (300K orders a day) is small enough that one database handles it with contempt. The architecture isn't balanced because the workload isn't.
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