In this chapter
We follow one fan's ticket purchase through every layer — user, browser, DNS, internet, CDN, load balancer, frontend, API, backend, cache, database, queue and back — and then the stack underneath it, marking where each Act's lesson lives. The whole year, in one journey.
The Problem in Real Life
After lunch, John hands Anna a marker. On the whiteboard, someone has already written in big letters: "Sold out in 41 minutes. 0 double bookings." Below it, the board is empty.
"One fan," he says. "Olivia Hart, in Leeds, on her phone, at 10:12. She bought two tickets. Draw everything that happened — every layer — and write which month you learned each one." Anna uncaps the marker. She doesn't need her notes.
If you can draw the whole journey, you understand the whole system.
John
Twenty-Six Separate Lessons vs. One Connected Picture
Pieces learned separately
A year of lessons can feel like a pile of unrelated topics.
Everything is connected
One click touches almost every idea in this course.
The real test
Seeing the whole picture is what turns knowledge into engineering judgement.
The Complete Request Journey, and the Stack Underneath
The relay race analogy: a ticket purchase is a relay race. The baton — Olivia's request — is passed from runner to runner: browser, DNS, internet, CDN, load balancer, backend, database, queue. Each runner has one job and must hand over cleanly. If any runner drops the baton, the race is lost. Here is the whole race, runner by runner.
- 1. User and browser (Acts 01, 12): Olivia taps "Buy 2 tickets" in the browser on her phone. The frontend (React, Act 12) sends
POST /v1/orderswith her session (Act 22) and the seats. - 2. DNS (Act 12): her phone looks up
blueticket.exampleand gets the load balancer's address (cached from earlier). - 3. Internet (Act 11): packets travel over mobile data, through her ISP and the internet's routers, using IP addresses, TCP and ports.
- 4. CDN and load balancer (Acts 12, 14, 19): images and the app's files already came from the CDN. The API request reaches the load balancer, which completes the TLS handshake with a valid certificate (Acts 12, 22 — this morning's lesson) and picks a healthy container.
- 5. API and backend (Acts 07–09, 23): in the container, the request passes the router, middleware (auth, rate limit, request ID) and the handler (Act 23). The code (Act 07) validates the input (Act 08), and runs logic built on the right data structures (Act 09).
- 6. Cache and database (Acts 09, 13, 14): the seat map came from Redis (cache). The seat hold and the order are written in a transaction in PostgreSQL (Act 13), with a unique constraint so seats C14 and C15 can't be sold twice.
- 7. Payment and queue (Acts 14, 22, 23): the payment is created with an idempotency key and a restricted key (Acts 22, 23); the webhook arrives, is verified and queued; a worker issues the tickets and queues an email and an SMS (Act 14), sent by workers in containers (Act 21).
- 8. Response, browser, user (Acts 03, 12): the API responds
201 Createdwith JSON (Acts 12, 23); the browser shows "You're going!" — text encoded in UTF-8 (Act 03) so "Zoë" in the band's name displays correctly. Olivia screams. Her phone buzzes with the SMS.
| Layer or practice | Acts |
|---|---|
| People, roles and teamwork | 01, 18, 24 |
| Hardware: CPU, memory, storage | 02 |
| Data, text and numbers as bits | 03 |
| Software, builds, runtimes, packages | 04, 16 |
| Operating system, processes, files, the terminal | 05, 06 |
| Programming, problem solving, data structures, memory | 07, 08, 09, 10 |
| Networks and the internet | 11 |
| The web: DNS, HTTP, HTTPS, browsers, caching, APIs | 12, 23 |
| Databases and transactions | 13 |
| System design: load balancers, caches, queues, scaling | 14 |
| Git and collaboration | 15 |
| Debugging and testing | 17 |
| Build, deploy, run, CI/CD | 19, 21 |
| Cloud and containers | 20, 21 |
| Security | 22 |
| Working in a real codebase | 25 |
| Everything together | 26 |
The complete request journey
User → Browser
Acts 01, 12, 22
DNS → Internet
Acts 11, 12
CDN / Load balancer (TLS)
Acts 12, 14, 19, 22
Frontend → API → Backend
Acts 07–09, 12, 23
Cache
Acts 09, 14
Database (transactions)
Act 13
Queue → workers
Acts 14, 21, 23
Response → Browser → User
Acts 03, 12, 23
Underneath every runner — the stack (Acts 02–06, 10): each machine in the race — Olivia's phone, the load balancer, the container, the database server — is the same tower: application → runtime (Act 04) → operating system with processes, memory and files (Acts 05, 06, 10) → CPU, memory and storage (Act 02) → the network (Act 11) → the internet → other systems (the payment and SMS providers, Act 23).
Around the race — how it was built and kept running: the code was written, reviewed and versioned with Git (Acts 15, 18, 24), set up with the right environment (Act 16), debugged and tested (Act 17), built and deployed by the pipeline (Acts 19, 21) to the cloud (Act 20), watched by monitoring (Acts 19, 21) and protected by security (Act 22) — by a team whose roles and ways of working were the very first thing Anna learned (Act 01).
The close: Samantha stands in front of the finished whiteboard for a long time. Then she turns to Anna: "A year ago you didn't know what a sprint was." Anna laughs. "A year ago I didn't know what a server was." John caps the marker. "And now you can draw the whole thing. That's what an engineer is."
Key Takeaway
One ticket purchase is a relay race through every layer: user and browser, DNS, the internet, CDN and load balancer (with TLS), the API and backend, cache and database (with transactions), payment, queue and workers, and back as a response to the browser. Under every machine sits the same stack — application, runtime, operating system, hardware, network — and around the whole race sit the practices that build and protect it: Git, testing, CI/CD, cloud, containers, monitoring and security. Seeing it all as one picture is what makes an engineer.
Why This Matters
"What happens when you buy a ticket online?" is really "explain the whole of computing" — and being able to answer it end to end, with the stack underneath, is one of the clearest signs that someone understands software, not just a framework. This picture is the map you'll keep adding detail to for the rest of your career.
Sale Day is over. The festival is sold out, and Anna can draw the whole system from memory. But John has one more idea: "You've understood BlueTicket. Now prove it to yourself — build something of your own, from nothing."