We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design Masterclass · Core Fundamentals
Free preview: the first 2 parts of this 9-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Core Fundamentals
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
It is easy and good
“It is really nice and good Please join the course”
Black Friday. Your e-commerce platform normally handles 5,000 requests per second. At midnight on Black Friday, traffic surges to 50,000 requests per second. By Sunday evening, it's back to 5,000.
If you provisioned enough servers to handle Black Friday traffic all year round, you'd be paying for 10x the capacity you need 363 days a year. That's like buying a 40-seat party bus for your daily commute, technically it gets you to work, but you're paying for 39 empty seats every single day.
On the other hand, if you only provision for normal traffic, your site crashes on the one day that matters most for revenue.
This is the problem elasticity solves. Not "how many servers do I need?" but "how do I automatically have the right number of servers at any given moment?"
The cloud's real superpower isn't that it gives you servers. It's that it gives you servers on demand, and takes them away when you don't need them anymore.
People use "scalability" and "elasticity" interchangeably. They shouldn't. They're related but distinct concepts.
Scalability is the ability to handle increased load. Can your system handle 10x more traffic if you throw resources at it? If yes, it's scalable.
Elasticity is automatically adjusting resources to match current demand. Your system scales up when traffic spikes and scales down when traffic drops, without anyone touching a button.
Here's the clearest way to see the difference:
| Scalable but NOT Elastic | Scalable AND Elastic | |
|---|---|---|
| Traffic spikes | Ops engineer manually adds servers at 3 AM | Auto-scaling adds servers in 60 seconds |
| Traffic drops | Servers sit idle until someone remembers to remove them | Auto-scaling removes servers, bill goes down |
| Cost | Overpay during low traffic, scramble during high traffic | Pay for what you use, when you use it |
| Human intervention | Required | Not required |
A system can be scalable without being elastic. If you can handle more load but only by manually provisioning servers, that's scalable. If the system does it automatically, that's elastic.
Every major cloud platform. AWS, GCP, Azure, has built auto-scaling as a core primitive specifically because elasticity is that important.