Scalability Fundamentals
Vertical vs. horizontal scaling, and load balancing — the baseline vocabulary every other system-design topic builds on.
Try answering in your head first, then click a question to check the model answer.
Q1.Why is horizontal scaling generally preferred over vertical scaling for large-scale systems, despite vertical scaling being simpler?(show answer)
Vertical scaling hits a hard ceiling — there's a maximum machine size available — and keeps the system dependent on a single point of failure. Horizontal scaling (adding more machines) has effectively no upper limit and improves fault tolerance (one instance failing doesn't take down the whole system), at the cost of added complexity: load balancing, data consistency across nodes, and needing the application to be stateless.
Q2.Why does statelessness matter for horizontally scaling an application tier?(show answer)
If a server stores session state locally (e.g. in memory), a user's subsequent requests must be routed to that exact same server, defeating the point of load balancing across many interchangeable instances — and that server becomes a single point of failure for anyone whose session lives there. Making servers stateless (session data externalized to a shared store like Redis) lets any instance handle any request, which is what actually makes horizontal scaling and load balancing work cleanly.
Q3.How do you identify the bottleneck in a system before deciding what to scale?(show answer)
Measure utilization and latency at each layer (load balancer, application servers, database, cache, downstream dependencies) under realistic load, and identify which component saturates first as load increases — that's the bottleneck. Scaling components that aren't the bottleneck wastes effort and cost without improving overall system throughput, since the system is only as fast as its slowest/most saturated component.
Q4.Why can scaling out the application tier alone fail to improve overall system throughput?(show answer)
If the database (or another shared downstream dependency) is the actual bottleneck, adding more stateless application servers just means more servers competing for the same limited downstream capacity — throughput plateaus at the bottleneck's ceiling regardless of how many application instances exist. This is why identifying the true bottleneck before scaling matters more than reflexively adding servers.