> ## Documentation Index > Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt > Use this file to discover all available pages before exploring further. # Vertical vs Horizontal Scaling > Comparison of vertical and horizontal scaling strategies for web apps, explaining trade-offs, operational considerations, and when to scale up versus scale out for capacity and reliability. Your photo app is growing: CPU is at \~80% and feeds are loading slower. To gain capacity there are two fundamental approaches — make a single server more powerful (vertical scaling) or run many servers in parallel (horizontal scaling). Each approach has trade-offs in cost, complexity, and reliability. ## Vertical scaling (scale up) Vertical scaling means increasing a single machine’s resources: more CPU, more RAM, faster disk. You keep the same application code and simply provision a larger instance. The image illustrates the concept of vertical scaling, showing how to make a server bigger by adding more CPU, RAM, and a faster disk, with a smartphone interface on the left and server icons on the right. Pros * Simple to implement — no app changes required. * Low operational overhead for small-scale apps. * Quick to get more capacity by resizing instances. Example: an unchanged server startup call remains valid. ```javascript theme={null} app.listen(80); ``` Drawbacks * Hard upper limit: you can only buy the biggest machine available. * Diminishing returns: higher tiers often cost disproportionately more for modest gains. * Single point of failure: one large server failing takes your whole app down. The image illustrates a scenario where a single large server failure causes an entire app to go down, depicted by a broken server icon and a mobile app interface showing errors. The text emphasizes "One big server is still one server" and "The whole app is down." When to use vertical scaling * Early stages or prototypes. * Predictable workloads that fit within the capacity of a single machine. * When minimizing operational complexity is a priority. ## Horizontal scaling (scale out) Horizontal scaling runs multiple instances of your app across many smaller servers. Add more machines as traffic grows. The image illustrates horizontal scaling using multiple small servers, showing that if one server fails, the others continue to function. It has a diagram with an app interface pointing to a grid of servers, with one marked as failed. Advantages * Virtually unlimited capacity by adding instances. * Higher availability: no single point of failure. * Cost efficiency at scale when using commodity instances or containers. Operational considerations * You need a load balancer to distribute requests across the fleet. * Shared state must be externalized (database, object storage, or shared cache) so any instance can serve any request. * More complexity: service discovery, orchestration (e.g., Kubernetes), monitoring, and autoscaling policies. When to use horizontal scaling * High and/or unpredictable traffic. * Requirements for high availability and fault tolerance. * Architectures built around microservices, containers, or distributed systems. ## At-a-glance comparison | Aspect | Vertical scaling (Scale Up) | Horizontal scaling (Scale Out) | | ----------------- | --------------------------------------- | ------------------------------------------------------ | | Complexity | Low | Higher (load balancing, orchestration) | | Cost pattern | Often nonlinear, expensive at top tiers | More predictable; benefits from commodity instances | | Failure domain | Single point of failure | Resilient to individual instance failures | | Capacity ceiling | Limited by largest machine | Practically unlimited by adding nodes | | Example use cases | Small apps, prototyping, simple stacks | Large-scale services, high availability, microservices | ## Practical rule of thumb Start with vertical scaling for simplicity and lower initial cost. Move to horizontal scaling when you hit vertical limits, need higher availability, or when traffic grows beyond what a single machine can handle. For further reading on building resilient, scalable systems, see: * [Kubernetes: Concepts](https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/) * [Load balancing patterns](https://en.wikipedia.org/wiki/Load_balancing_\(computing\)) * [Object storage for shared assets (S3-like)](https://aws.amazon.com/s3/) Start simple, monitor key metrics (CPU, memory, latency, error rates), and evolve your architecture to match your traffic, availability, and cost requirements.