# Horizontal scaling vs Vertical scaling > Horizontal scaling adds instances to spread work; vertical scaling gives an existing instance more CPU, memory, or I/O capacity. Choose vertical scaling when a larger machine solves the bottleneck with less complexity, and horizontal scaling when you need capacity beyond one machine or enough independent instances to tolerate failures. Source: https://sysround.com/compare/horizontal-scaling-vs-vertical-scaling Updated: 2026-11-05 ## Side by side | | Horizontal scaling | Vertical scaling | |---|---|---| | What changes | More instances share the workload | An instance gets more resources | | Capacity ceiling | Limited by partitioning, coordination, and shared dependencies | Limited by available machine sizes and resource utilization | | Application changes | Needs routing and a plan for shared or partitioned state | Often fewer application changes | | Database scaling | Read replicas or shards, depending on the bottleneck | More RAM, CPU, storage capacity, or I/O throughput | | Failure handling | Can tolerate instance loss with redundancy and spare capacity | A larger instance still needs separate failover | | Scaling operation | Provision, route traffic, and sometimes rebalance data | Resize or replace; may require restart or failover | | Cost | More instances, network traffic, and operational overhead | Larger instance pricing and possible licensing changes | | Performance | Raises aggregate throughput when work is distributable | Can improve throughput or latency if added resources help | | Operational complexity | Membership, routing, partial failures, and coordination | Simpler topology, but upgrades still need planning | ## The differences that matter The bottleneck determines whether either option helps. Adding API instances will not fix a saturated database, and adding CPU will not fix contention on one locked record. Start with CPU, memory, I/O, connection limits, and lock contention rather than assuming traffic growth requires more machines. Horizontal scaling requires work to be distributed. Stateless request handlers can sit behind a load balancer, while connection-heavy services need routing and reconnect behavior. Stateful storage usually needs replication for read capacity or partitioning for distributed write and storage capacity; replicas do not automatically increase a single leader's write capacity. Vertical scaling keeps more work within one machine, avoiding some network calls and distributed coordination. It can be a practical way to preserve local transactions or fit a working set in memory. However, extra cores will not accelerate a serial execution path, and eventually the available machine sizes impose a ceiling. Scaling and availability are separate decisions. Multiple instances improve availability only if routing, failure detection, state recovery, and remaining capacity work together. A vertically scaled database can still have a failover replica, while a horizontally scaled application can still depend on a single database that takes the whole service down. ## Choose Horizontal scaling when - Independent API requests or background jobs can be spread across instances, and demand exceeds what one practical machine can handle. - The service must keep serving after an instance fails, with enough spare capacity and no unprotected shared dependency. - Traffic varies enough that adding and removing instances is useful, and startup time fits the expected traffic ramp. - Data volume or write throughput requires partitioning, and the design can handle shard routing, skew, and cross-shard operations. ## Choose Vertical scaling when - The workload still fits a practical machine size, and avoiding distributed coordination is more valuable than adding nodes. - Measurements show that more memory, CPU, or I/O capacity directly addresses the limiting resource. - A transactional database needs more near-term capacity, but sharding would introduce unnecessary cross-shard transaction complexity. - The team needs a simpler capacity increase while preparing a longer-term partitioning plan and maintaining separate failover protection. ## Worked example: Scaling an API without hiding its database limit Assume load tests show one API instance meets the latency target at 800 requests per second, but you budget 600 to retain headroom. A peak of 12,000 requests per second needs 20 instances; 21 can sustain that peak after one instance fails, assuming balanced traffic and sufficient downstream capacity. Horizontal scaling fits because requests are independent and sessions live outside the instances. A larger instance could also work if testing shows proportional gains, but it would not provide instance-level redundancy by itself. Before adding capacity, check the database: if it already saturates at 9,000 requests per second, neither more API instances nor larger API machines will deliver the target. ## In the interview - Name the tier and bottleneck before choosing: API CPU, worker backlog, database writes, and cache memory can require different scaling strategies. - Estimate peak load and usable per-instance capacity at the latency target. Include headroom and capacity after the failure you promise to tolerate, not just average utilization. - For horizontal scaling, explain request routing, state ownership, and the next shared bottleneck. Expect follow-ups about hot keys, rebalancing, retries, and duplicate execution. - For vertical scaling, explain why the additional resources help and where the ceiling is. Describe the resize procedure, possible interruption, and the signal that would trigger a move to horizontal scaling. ## Common mistakes - Claiming horizontal scaling is automatically cheaper or linear. Coordination, skew, shared dependencies, and network traffic can limit gains. - Treating more instances as high availability without discussing independent failure domains, failover, and surviving capacity. - Assuming a larger machine fixes every performance problem. Serial code, lock contention, and downstream limits may remain unchanged. - Saying SQL databases can only scale vertically, or that adding replicas automatically scales writes. Relational databases can use replicas and sharding, with different trade-offs. ## Interview questions where it comes up - [Design a URL shortener like Bitly](https://sysround.com/questions/design-url-shortener): Redirect handlers can scale horizontally while cache capacity, hot keys, and database throughput require separate scaling decisions. - [Design a notification system](https://sysround.com/questions/design-notification-system): Worker capacity can grow horizontally, but provider limits and queue partitioning determine whether additional workers improve throughput. - [Design a distributed cache](https://sysround.com/questions/design-distributed-cache): Larger cache nodes postpone memory limits, while adding nodes requires ownership changes, rebalancing, and a plan for hot keys. - [Design a distributed key-value store](https://sysround.com/questions/design-key-value-store): The design must distinguish increasing node capacity from partitioning data and replicating it for durability and availability. ## FAQ ### What is the difference between horizontal and vertical scaling? Horizontal scaling adds instances and distributes work among them. Vertical scaling increases resources on an existing instance, such as CPU, memory, or I/O capacity. Many systems use both at different tiers. ### Is horizontal scaling better than vertical scaling? Neither is universally better. Horizontal scaling supports distributed capacity and can support failure tolerance, but adds routing and coordination complexity. Vertical scaling is often simpler when the workload fits one machine and added resources address the actual bottleneck. ### Can you scale a database both horizontally and vertically? Yes. You can give database nodes more resources, add replicas for eligible reads, and partition data across nodes for distributed storage and write capacity. The right combination depends on query patterns, consistency requirements, and whether load is concentrated on a few records or partitions. ## Related concepts - [Load balancing](https://sysround.com/concepts/load-balancing) - [Stateless services](https://sysround.com/concepts/stateless-services) - [Database sharding](https://sysround.com/concepts/database-sharding) - [Autoscaling](https://sysround.com/concepts/autoscaling) - [Back-of-the-envelope estimation](https://sysround.com/concepts/back-of-the-envelope-estimation) --- SysRound (https://sysround.com) is an AI practice tool for system design interviews: a voice or typed AI interviewer, a shared whiteboard, then feedback on every skill and a model answer. Its feedback is AI-generated and can be wrong.