The Story
A travel blogger with a big following tweets about your trip planner. “This app is incredible. Just planned my entire Japan trip in 30 seconds.” The link is right there. Their followers click.
Five hundred users hit your app in the first minute. Your server handles it. A little slow, but fine. Then the tweet goes viral. Five thousand users in ten minutes. Your server starts struggling. Response times go from half a second to five seconds. Then ten seconds. Then the app stops responding entirely.
Your monitoring from Lesson 20 is screaming. Your phone is buzzing. Sentry is full of timeout errors. BetterStack says the site is down. You’re watching the biggest moment your app has ever had — the moment everyone is trying to use it — and it’s dead.
You restart the server. It comes back up for a minute, gets overwhelmed again, and dies. The problem isn’t a bug. The problem is physics. One server has a limited amount of CPU, memory, and network capacity. When more users show up than one server can handle, no amount of code optimization will save you. You need more servers.
This is the scaling wall. And it’s one of the most important concepts in software architecture. Your app shouldn’t depend on a single computer. It should be able to run on two computers, or ten, or a hundred. When traffic spikes, you add more copies. When traffic drops, you remove them. The app doesn’t care which computer it’s running on. It just runs.
The tool that makes this work is a load balancer — a traffic cop that sits in front of your servers and distributes incoming requests across all of them. Let’s set one up.
This lesson continues with the full course
The story intro above is free to read. The full lesson — prompts, explanations, and adapt-it exercises — requires the Full Course ($249) tier or above.