Horizontal vs Vertical Scaling in System Design

When an application starts receiving more traffic, we need to increase its capacity.

There are two common ways to do this:

• Vertical Scaling – Make an existing server more powerful.
• Horizontal Scaling – Add more servers.

Understanding the difference is important when designing applications that need to handle increasing traffic.

Vertical Scaling

Vertical scaling is also called scaling up.

We increase the resources of an existing server.

For example, suppose our ASP.NET Core application runs on a server with:

4 CPU cores
16 GB RAM

We can increase it to:

16 CPU cores
64 GB RAM

The application is still running on one server.

flowchart LR
    Users --> Server
    Server --> Database

Real-World Example

Suppose an ASP.NET Core API is using 90% CPU because of increased traffic.

One option is to increase the server's CPU and memory.

flowchart LR
    Users --> LargeServer
    LargeServer --> Database

This can be simple because we don't necessarily need to change the application architecture.

Advantages of Vertical Scaling

• Simple to implement.
• Usually requires fewer application changes.
• Useful when the workload can be handled by a larger machine.
• Can be useful for certain database workloads.

Limitations of Vertical Scaling

• A server has a physical or platform-specific maximum capacity.
• A larger server can become expensive.
• The server can still be a single point of failure.
• Increasing hardware does not provide unlimited scalability.

For example, we cannot keep increasing CPU and RAM forever.

Horizontal Scaling

Horizontal scaling is also called scaling out.

Instead of making one server bigger, we add more servers.

flowchart LR
    Users --> LoadBalancer
    LoadBalancer --> Server1
    LoadBalancer --> Server2
    LoadBalancer --> Server3

Each server runs the same application.

The Load Balancer distributes requests between them.

ASP.NET Core Example

Suppose we have an ASP.NET Core API:

[ApiController]
[Route("api/products")]
public class ProductsController : ControllerBase
{
    [HttpGet]
    public IActionResult GetProducts()
    {
        return Ok(new[]
        {
            "Laptop",
            "Mobile",
            "Monitor"
        });
    }
}

We can run the same application on multiple servers.

flowchart LR
    User --> LoadBalancer
    LoadBalancer --> API1
    LoadBalancer --> API2
    LoadBalancer --> API3

If traffic increases, another application server can be added.

Why Horizontal Scaling Works Well for Stateless APIs

Horizontal scaling becomes easier when application servers are stateless.

For example, if API1 receives a request and API2 receives the next request, both servers should be able to process the request without depending on local memory from API1.

flowchart LR
    User --> LoadBalancer
    LoadBalancer --> API1
    LoadBalancer --> API2
    API1 --> Database
    API2 --> Database

This is one reason stateless application architecture is commonly used for scalable web APIs.

What About SQL Server?

Adding more API servers does not automatically scale the database.

For example:

flowchart LR
    LoadBalancer --> API1
    LoadBalancer --> API2
    LoadBalancer --> API3
    API1 --> Database
    API2 --> Database
    API3 --> Database

All three API servers are still communicating with the same SQL Server.

If SQL Server becomes the bottleneck, adding more API servers may not solve the problem.

We may need database-specific strategies such as:

• Query optimization
• Proper indexing
• Caching
• Read replicas
• Partitioning
• Archiving

Vertical vs Horizontal Scaling

Vertical Scaling	Horizontal Scaling
Increase server capacity	Add more servers
Scale up	Scale out
Usually simpler	Requires distributed architecture considerations
Has hardware or platform limits	Can add more instances as required
One larger server may remain a dependency	Multiple servers can provide redundancy

Real-World Example: E-Commerce Application

Imagine an e-commerce application normally receiving 2,000 requests per second.

During a major sale, traffic increases to 20,000 requests per second.

With vertical scaling, we could increase the capacity of the existing server.

flowchart LR
    Users --> LargeServer
    LargeServer --> Database

With horizontal scaling, we can add more application servers.

flowchart LR
    Users --> LoadBalancer
    LoadBalancer --> API1
    LoadBalancer --> API2
    LoadBalancer --> API3
    LoadBalancer --> API4
    API1 --> Database
    API2 --> Database
    API3 --> Database
    API4 --> Database

The second architecture gives us more application processing capacity and also allows traffic to continue if one application instance fails.

Can We Use Both?

Yes.

Real-world systems can use both approaches.

For example, we might increase the CPU and memory of each API server and also run multiple API servers.

flowchart LR
    Users --> LoadBalancer
    LoadBalancer --> LargeAPI1
    LoadBalancer --> LargeAPI2
    LoadBalancer --> LargeAPI3

Here, each server has been vertically scaled, while multiple servers provide horizontal scaling.

When Should We Use Vertical Scaling?

Vertical scaling can be useful when:

• The workload is stil