EXERCISE
1A single server has limits. When traffic exceeds capacity, response times spike, then the server crashes. Users see error pages. Your business loses money.
You built an e-commerce site. Launched successfully. Initially, 100 concurrent users. One server handles everything smoothly.
Black Friday arrives. Traffic explodes. 10,000 concurrent users hit your site.
What happens?
Your single server drowns. CPU hits 100%. Memory maxes out. Requests queue up. Response time jumps from 100ms to 30 seconds. Users get frustrated. Many leave. Server crashes entirely. Site goes down.
Revenue lost. Reputation damaged.
Limited Resources: Every server has finite CPU, memory, and network capacity. Exceed those limits and performance collapses.
Single Point of Failure: Hardware fails. Software crashes. Network issues occur. When your only server dies, your entire application dies.
Cannot Scale: Need more capacity? Upgrading one server (vertical scaling) hits physical limits and costs explode.
Add more servers! But now a new problem appears.
Multiple Servers, New Problems:
Users need to know which server to connect to. Do they manually choose? What if they pick the overloaded server while others sit idle?
How do servers coordinate? How do you ensure even distribution?
When a crashes, how do users know to try a different one?
This chaos needs organization. Enter the load balancer.
Target (2013): Website crashed during Black Friday sale. Single point of failure cost millions in lost sales.
Healthcare.gov launch: Initial deployment could not handle traffic. Poor load distribution caused catastrophic failures.
Your application: Without , growth itself becomes your enemy. Success kills your service.
