In this chapter
With fans flowing again, Anna watches the application layers take the Sale Day wave — frontend, API and backend, database transactions, the cache, the queue and workers, and payment recovery — reviewing Acts 09, 12, 13, 14 and 23, explained as a restaurant on its busiest night ever.
The Problem in Real Life
10:06. The waiting room lets fans in at a steady pace. On the wall screen, tickets sold climbs faster than anyone has ever seen: 1,000, 5,000, 12,000. Samantha sits down for the first time.
Anna keeps watching the dashboards — not because something is wrong, but because she wants to see it: every part of the system she spent a year learning about, doing its job at the same moment.
Every box on the diagram is working at once. I can see all of them.
Anna
One Server Doing Everything vs. Every Layer Doing Its Own Job
50,000 people at once
The same seat map, the same seats, the same payment page — all at the same second.
Two fans, one seat
Thousands of fans click the same front-row seats within milliseconds of each other.
Slow outside services
SMS, email and payment providers are under pressure too.
Frontend, Backend, Database, Cache, Queues and Workers
The restaurant analogy, one last time: on its busiest night, a well-run restaurant works because every station does its own job. The host seats guests at a steady pace. Waiters take orders. The kitchen cooks. Popular dishes are prepared in advance. Order tickets queue on the rail so cooks aren't overwhelmed. And each table can only be booked once. BlueTicket on Sale Day is exactly that restaurant.
- Frontend — the dining room (Act 12): the React app in each fan's browser shows the seat map and sends API requests. Its files come from the CDN, so the servers never send them.
- API and backend — the waiters and the kitchen (Acts 12, 14, 23): each request passes through the router, middleware (auth, rate limits) and handlers (Act 23), on stateless app containers that can be added at any time (Act 14).
- Cache — dishes prepared in advance (Acts 09, 12, 14): the seat map for the festival is asked for millions of times in the first ten minutes. It's served from Redis in under a millisecond, refreshed every second, so the database answers only a tiny fraction of those requests. Cache hit rate: 99.2%.
- Database and transactions — each table booked once (Act 13): when two fans click seat C14 in the same millisecond, the database's transaction and unique constraint let exactly one succeed; the other gets a clean "seat taken, choose another" (409, Act 23). The seat-hold logic from Act 08 gives each fan 10 minutes to pay. By the end of the hour: zero double bookings.
- Queues and workers — the order rail (Acts 14, 21): every sold ticket creates an SMS and an email. At peak, that's 900 messages a second — far more than the SMS provider accepts. The queue holds them and the workers send them at the provider's limit. Fans get their texts a few minutes late; nothing is lost and checkout never slows down.
- Payments and recovery — never trust one message (Act 23): under the load, the payment provider's webhooks start arriving slowly. For 212 fans, they don't arrive at all. Every 5 minutes, the reconciliation job asks the provider for recent successful payments and creates any missing orders. All 212 get their tickets. Not one paid order is lost.
- Bots — kept out of the dining room (Act 22): rate limits block 18,000 automated requests per minute at the peak, and the per-account limit stops any single account buying more than six tickets.
| Layer | Restaurant version | Taught in | Sale Day number |
|---|---|---|---|
| Cache | Dishes prepared in advance | Acts 09, 12, 14 | 99.2% of seat-map requests |
| Transactions | Each table booked once | Acts 08, 13 | 0 double bookings |
| Queue + workers | The order rail | Acts 14, 21 | 900 messages/second at peak, none lost |
| Reconciliation | Checking the order book | Act 23 | 212 paid orders recovered |
| Rate limits | The doorman | Act 22 | 18,000 bot requests/minute blocked |
The application layers on Sale Day
Frontend (React, from the CDN)
seat map in the browser
API + backend (stateless containers)
auth · rate limits · handlers
Redis cache
seat map · 99.2% hits
PostgreSQL
transactions · 0 double bookings
Queue → workers
900 SMS/emails per second, none lost
Reconciliation
212 payments recovered
10:30 — the pattern: none of this is luck. Each piece was added after something went wrong earlier in the year: the slow seat search (Act 09), the double-sold seat (Act 13), the SMS that froze checkout (Act 14), the lost payments (Act 23), the bots (Act 22). Anna realises that the system on the screen is really a list of lessons, each one written into code.
Key Takeaway
Under Sale Day load, every application layer does its own job, like stations in a busy restaurant: the frontend runs in browsers from the CDN; stateless backends answer API requests; the cache serves the hottest data in microseconds; database transactions and unique constraints let each seat be sold exactly once; queues and workers absorb message spikes without slowing checkout; reconciliation recovers payments whose webhooks never arrived; and rate limits keep the bots out.
Why This Matters
This is what system design looks like when it works: no single clever trick, but many simple, well-understood pieces — cache, transactions, queues, idempotent recovery, rate limits — each doing one job. Being able to name each piece and explain why it's there is exactly what system-design interviews ask for.
The application layers are holding. But underneath them, the infrastructure is working just as hard: the cloud, the containers, the pipeline, the monitoring and the security that let the team fix things at 10:04 in the first place.