Define Scalability.
Scalability is the ability of a system to handle increasing amounts of work by adding resources, while maintaining or improving performance metrics like latency and throughput.
Scalability refers to a system's capacity to grow and manage increased demand without compromising performance. It's not simply about handling more users or data; it's about doing so in a cost-effective and sustainable manner. A truly scalable system can be expanded to meet growing needs by adding resources (like more servers or storage) rather than requiring a complete redesign.
- 1
Vertical Scaling (Scaling Up): Adding more power to an existing server (more CPU, RAM, faster storage). This is often simpler but has physical and cost limits. Example: Upgrading a database server from 16GB to 64GB of RAM.
- 2
Horizontal Scaling (Scaling Out): Adding more servers to a pool of resources. This is the foundation of modern cloud architecture and offers theoretically limitless growth. Example: Adding more web servers behind a load balancer to handle more concurrent users.
- 1
Load Scalability: The ability to handle a growing number of concurrent users or requests. Example: A website that maintains sub-second response times during a flash sale.
- 2
Data Scalability: The ability to manage increasing volumes of data without performance degradation. Example: A data warehouse that continues to deliver fast queries as it grows from terabytes to petabytes.
- 3
Geographical Scalability: The ability to serve users across different regions with low latency. Example: A global content delivery network (CDN) distributing content from edge locations.
- 4
Administrative Scalability: The ability to manage a growing system without a linear increase in operational complexity. Example: Using Infrastructure as Code to manage thousands of servers with the same effort as managing a handful.
The primary inhibitor of scalability is often state—specifically, shared state that must remain consistent across a distributed system. Stateless services (like a web server that doesn't store user sessions) can be scaled horizontally almost arbitrarily by simply adding more instances behind a load balancer. Stateful services (like a database) require careful design to scale, often involving techniques like sharding (partitioning data across nodes) and replication, which introduce complexity.
Scenario Questions
- 1
Your app gets 10x more users overnight and starts timing out — what are the first three things you’d check to make it handle the load?
- 2
You’re building a simple API that serves user profiles — how would you design it so it can handle 1000 requests per second instead of 100?
- 3
If you add more servers but the database becomes the bottleneck, what’s the most likely cause and how would you fix it?
- 1
Our user feed feature started slowing down after we doubled traffic — we added more app servers but nothing changed. What’s going on and how would you debug it?
- 2
We scaled our auth service horizontally but now sessions are inconsistent across instances — what design flaw caused this and how do you fix it without changing the database?
- 3
A new feature caused our cache hit rate to drop from 95% to 40% under load — what could be the root cause and how would you redesign the caching strategy?
- 1
You’re designing a real-time notification system that needs to scale to millions of concurrent users — what components would you shard, and how would you handle consistency vs. latency tradeoffs?
- 2
Our payment service is hitting 500ms p99 latency at 10K RPS — we’ve scaled the app tier and optimized queries. What’s the next layer you’d investigate and why?
- 3
How would you design a scalable message queue that handles bursts of 1M messages/hour without losing data or overloading consumers?
- 1
We’re migrating a monolithic e-commerce system to microservices — how do you prioritize which components to scale first, and what long-term operational costs are you willing to accept?
- 2
Our legacy billing system can’t scale horizontally due to shared state — how would you architect a phased migration to a scalable stateless model without disrupting revenue reporting?
- 3
A critical service is hitting 99.99% uptime targets but scaling costs are growing exponentially — how do you balance cost, reliability, and future growth when making architectural tradeoffs?
Follow-up Questions
- ❓How would you know if your scaling strategy is actually working?
- ❓What happens when you scale a database that isn’t sharded?
- ❓Why did adding more servers not improve response time?