Scalability vs elasticity in the cloud
a precise distinction often blurred.
scalability is the ability to handle more load by adding capacity; elasticity is automatically adding AND removing capacity in real time to match demand.
WHAT THIS TESTS The interviewer is checking precision. Many candidates conflate scalability and elasticity, so the question rewards a clear distinction and an example that specifically demonstrates automatic contraction, which is what makes something elastic rather than merely scalable.
A GOOD ANSWER COVERS Scalability is the capability of a system to handle increased load by adding capacity, whether vertically by using bigger machines or horizontally by adding more machines. It speaks to whether the architecture can grow, and the act may be planned or even manual. Elasticity is narrower and dynamic: it is the ability to automatically provision more resources when demand rises and, crucially, release them when demand falls, in near real time, so capacity continuously tracks load. The key differentiator is the automatic two-way adjustment, especially scaling back down to avoid paying for idle capacity. A system can be scalable but not elastic, for example one you can grow but only by manual intervention.
COMMON WRONG ANSWERS Saying the two are the same. Giving an example that only scales up and never scales down, which demonstrates scalability, not elasticity. Confusing vertical scaling with elasticity. Forgetting the automatic, demand-driven nature of elasticity.
LIKELY FOLLOW-UPS How does an auto-scaling policy decide when to add or remove instances? What metrics drive it, CPU, queue depth, request latency? What are the risks, such as thrashing or cold starts, of aggressive elasticity? How do serverless functions embody elasticity?
ONE CONCRETE EXAMPLE An online store runs its web tier behind a load balancer in an auto-scaling group with a policy: keep average CPU near 60 percent. During a flash sale, traffic surges, CPU climbs, and the group automatically launches additional instances to absorb it. When the sale ends and traffic drops, the policy automatically terminates the extra instances, returning to the baseline. That automatic up-and-down adjustment is elasticity. A merely scalable design could also add instances during the sale, but if removing them required an engineer to act manually afterward, it would not be elastic.
Read the original → cloud.google.com
Get five bites like this every day.
Tezvyn delivers a daily feed of 60-second tech bites with quizzes to lock in what you learn.