Reasoning Checkpoint
A design challenge, worked through in writing — no auto-grading, just a real attempt.
The Challenge
Before signing off the Sale Day plan, John gives Anna a diagram of BlueTicket as it was on the Friday of the comedy-show crash — and asks her to review it the way a senior engineer would.
The diagram: Fans → DNS → CDN → one server running the whole monolith (pages, API, pricing, holds, payments, emails, and SMS sent inside checkout) → one PostgreSQL database and one Redis. The SMS provider and the payment company are outside, called directly during checkout.
What Your Review Needs
- Read the diagram using the four-step method: start at the user, follow a ticket purchase, and name the boundaries.
- List every single point of failure, and for each, say what stops working if it disappears.
- Name the slow part that caused Friday's crash, and the pattern that fixes it.
- Say whether the server should be scaled vertically or horizontally for Sale Day, and what must be true about the servers first.
- Propose the improved architecture as a short list of boxes and arrows (like the Sale Day diagram), and say which data you'd cache and which you never would.
Stuck? A Few Hints
- Ask "if this disappears, what stops?" for every box — including ones outside your boundary.
- What did fans wait for that they didn't need to watch?
- Where do sessions live, and why does that matter for horizontal scaling?
Before You Move On
This is a real architecture review — the same thinking senior engineers use before every big launch. You didn't need microservices or anything exotic: one queue, a load balancer, stateless copies and spares for every single point of failure took BlueTicket from "falls over at 2,000" to "ready for 50,000". The System Design Fundamentals course goes much further.