# 🔀 Horizontal vs. Vertical Scaling

## Introduction 🚀

In the world of system design, scaling is a crucial concept that determines how well an application can handle growth and increased load. There are two primary approaches to scaling: Horizontal Scaling and Vertical Scaling. This page will explore both concepts, their advantages, disadvantages, and provide examples to illustrate their implementation I have executed in differen system designs.

### Horizontal Scaling (Scaling Out) 🔀

Horizontal scaling, also known as scaling out, involves adding more machines to your pool of resources. This approach distributes the load across multiple servers.

#### Advantages:

* Improved fault tolerance and reliability
* Easier to scale on-demand
* Theoretically unlimited scaling potential

#### Disadvantages:

* More complex architecture
* Increased networking overhead
* Data consistency challenges

### Vertical Scaling (Scaling Up) ⬆️

Vertical scaling, or scaling up, involves adding more power (CPU, RAM, Storage, etc.) to an existing machine.

#### Advantages:

* Simpler to implement
* Less complex architecture
* Reduced software licensing costs

#### Disadvantages:

* Limited by hardware capabilities
* Potential for longer downtimes during upgrades
* Higher risk of single point of failure

### Comparison Table: Horizontal vs Vertical Scaling

| Aspect           | Horizontal Scaling                                    | Vertical Scaling                                      |
| ---------------- | ----------------------------------------------------- | ----------------------------------------------------- |
| Definition       | Adding more machines to the resource pool             | Adding more power to existing machines                |
| Scalability      | Theoretically unlimited                               | Limited by hardware capabilities                      |
| Complexity       | More complex architecture                             | Simpler to implement                                  |
| Fault Tolerance  | Higher (distributed system)                           | Lower (single point of failure)                       |
| Performance      | Can handle more concurrent operations                 | Better for handling large, complex operations         |
| Cost             | Can be more cost-effective for large-scale operations | Can be expensive for high-end hardware                |
| Flexibility      | Easier to scale on-demand                             | Less flexible, may require downtime for upgrades      |
| Data Consistency | More challenging to maintain                          | Easier to maintain                                    |
| Example Use Case | Web servers, distributed databases                    | CPU-intensive applications, large in-memory databases |

This comparison table summarises the key differences between horizontal and vertical scaling, highlighting their respective strengths and weaknesses across various aspects of system design and performance.

### Comparison Graph 📊

<figure><img src="/files/uqytOz9MsBzjdn0BpH8Z" alt=""><figcaption></figcaption></figure>

### Technical Architecture Diagram 🏗️

<figure><img src="/files/WI2vgg2XBMcf5d9J77lK" alt=""><figcaption></figcaption></figure>

### User Flow Diagram 🔄

<figure><img src="/files/vQaa4Zfs6iWvs3TETUKh" alt=""><figcaption></figcaption></figure>

### Code Snippet: Load Balancing Example (Node.js) 💻

```jsx
const cluster = require('cluster');
const http = require('http');
const numCPUs = require('os').cpus().length;

if (cluster.isMaster) {
  console.log(`Master ${process.pid} is running`);

  // Fork workers.
  for (let i = 0; i < numCPUs; i++) {
    cluster.fork();
  }

  cluster.on('exit', (worker, code, signal) => {
    console.log(`worker ${worker.process.pid} died`);
  });
} else {
  // Workers can share any TCP connection
  // In this case it is an HTTP server
  http.createServer((req, res) => {
    res.writeHead(200);
    res.end('Hello World\\n');
  }).listen(8000);

  console.log(`Worker ${process.pid} started`);
}
```

### Real-world Example: Netflix 🎬

Netflix is a prime example of a company that effectively uses both horizontal and vertical scaling:

#### Horizontal Scaling:

* Content Delivery Network (CDN): Netflix uses multiple servers worldwide to distribute content, reducing latency and improving user experience.
* Microservices Architecture: Netflix's system is broken down into small, independent services that can be scaled individually based on demand.

#### Vertical Scaling:

* High-performance Servers: For certain critical components, Netflix uses powerful servers to handle complex operations like video encoding.

### Scaling Visualisation: API Request Handling 📊

This diagram illustrates how horizontal and vertical scaling affect a server's ability to handle API requests:

<figure><img src="/files/A8vsHpdhx4PxtF9NDEkv" alt=""><figcaption></figcaption></figure>

In this visualisation:

* Horizontal Scaling: Multiple smaller servers each handle a portion of the total requests, distributed by a load balancer.
* Vertical Scaling: A single, more powerful server handles all requests directly.

Both approaches result in the same total capacity (300 requests/second in this example), but with different architectures and trade-offs as discussed earlier.

### Conclusion 🎯

Both horizontal and vertical scaling have their place in modern system design. The choice between the two (or a combination of both) depends on factors such as the nature of the application, budget constraints, and scalability requirements. A well-designed system often incorporates elements of both scaling strategies to achieve optimal performance and reliability.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://www.mohitkapadiya.com/system-design/horizontal-vs.-vertical-scaling.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
