Suggest an edit

Improve this article

Refine the answer for “Vertical vs horizontal scaling”. Your changes go to moderation before they’re published.

Approval required

Content

What you’re changing

Title (EN)

Short answer (EN)

Shown above the full answer for quick recall.

Answer (EN)

## 1. What scaling is

**Scaling** is the process of adding compute resources
so an application can handle **more requests**, **users** or **data** without degrading performance.

There are two main approaches:

- **Vertical scaling** (scale-up)
- **Horizontal scaling** (scale-out)

## 2. Vertical scaling (scale-up)

> Vertical scaling = **make one server more powerful**.

In other words:

> we **upgrade the hardware**: more CPU, RAM, SSD, or faster networking on one machine.

### Example:

| Before | After |
|---|---|
| 2 CPU cores | 8 CPU cores |
| 4 GB RAM | 32 GB RAM |
| HDD | NVMe SSD |

Now the same server can handle **4-8 times more** requests,
but it's still **one** server running **one** application process.

### An example in Node.js:

- There was one process handling 1,000 requests/sec.
- More CPU and RAM were added.
- Now that process handles 5,000 requests/sec.
- Or a **cluster via** `cluster` was started to use every CPU core.

All of this is **vertical scaling**, because it uses **one machine**.

### Advantages of vertical scaling

| Advantage | Description |
|---|---|
| Simplicity | No need to change the architecture or the code |
| Less infrastructure | One server, fewer points of failure |
| Fast to roll out | Just upgrade the hosting plan or hardware |
| Good for databases | Simple setups (Postgres, Mongo) scale up well |

### Drawbacks of vertical scaling

| Drawback | Description |
|---|---|
| A physical ceiling | Every server has a limit on cores and memory |
| Expensive | More powerful machines cost **non-linearly more** |
| A single point of failure | One server means one point of failure |
| Can't scale "forever" | Past the resource ceiling, you have to switch to horizontal |

## 3. Horizontal scaling (scale-out)

> Horizontal scaling = **add more servers**.

In other words:

> instead of strengthening one server,
> we **run several identical copies** of the app and **spread the load across them**.

### Example:

| Before | After |
|---|---|
| 1 server | 5 servers |
| Handling 1,000 req/s | Handling 5,000 req/s |
| One instance | 5 instances behind a load balancer |

Now if 5,000 users show up,
a load balancer (for example, **NGINX**, **AWS ELB**, **Kubernetes**) spreads the requests across every node.

### An example in Node.js:

- You have an app `app.js` listening on port `3000`.
- You run **5 copies** on different servers or containers.
- **NGINX** or a **load balancer** sits in front, handing out requests in turn.

This is **horizontal scaling**,
because you're adding **new nodes**, not strengthening one.

### Advantages of horizontal scaling

| Advantage | Description |
|---|---|
| Scales almost without limit | Just add more nodes |
| Resilience | If one server goes down, the rest keep working |
| Flexibility | You can scale by zone, region or container |
| Cost-effective | Several simple machines beat one "monster" |
| A good fit for the cloud | AWS, GCP, Azure, Kubernetes are all built for this |

### Drawbacks of horizontal scaling

| Drawback | Description |
|---|---|
| Architectural complexity | Requires load balancers, synchronization, logging |
| State issues | User sessions and caches need to live centrally (Redis, a database) |
| Cross-server communication | Adds network latency and harder debugging |
| DevOps skills required | Hard without containerization and CI/CD |

## 4. Comparison: vertical vs horizontal

| Criterion | Vertical (scale-up) | Horizontal (scale-out) |
|---|---|---|
| Core idea | Strengthen one server | Add more servers |
| Ease of implementation | Simple | Harder (needs a load balancer) |
| Code changes | Minimal | Often required |
| Growth limit | There is one (hardware is finite) | Almost unlimited |
| Resilience | One server is an SPOF | High (several instances) |
| Cost | Expensive at high capacity | Scalable and predictable |
| Node.js example | `cluster` (1 server, every core) | Nginx + several servers/containers |
| Type of scaling | "up" | "out" |

## 5. Both approaches are often combined

In practice, a **hybrid** is common:

1. **Vertically**: get the most out of one machine (CPU, RAM, `cluster`).
2. **Horizontally**: add more machines, containers, or pods (via Docker/Kubernetes/PM2 cluster mode).

An example architecture:

```javascript
Load Balancer (NGINX)
      │
 ┌────┴────┬────┬────┐
 │  Server1 │  Server2 │  Server3 │
 │ (a cluster of 8 workers each) │
```

→ Every machine uses **every core** (vertical),
while load is spread **across servers** (horizontal).

## Summary

| Parameter | Vertical | Horizontal |
|---|---|---|
| Scaling | Increasing one server's power | Adding new servers |
| Simplicity | Easier | Harder |
| Performance | Grows to the CPU/RAM ceiling | Grows linearly as nodes are added |
| Resilience | Low | High |
| Use case | Small/medium loads, databases | High-load systems, APIs |
| Node.js example | `cluster` | Several instances behind a load balancer |

**Conclusion:**

> **Vertical scaling** strengthens **one server** (more resources).
> **Horizontal scaling** adds **new servers**, running in parallel.
>
> Production usually combines both:
> `cluster` to use every CPU core,
> and a load balancer (NGINX, Kubernetes, PM2) to spread load across several nodes.

Markdown · drag & drop images · ⌘B / ⌘I shortcuts890 words

For the reviewer

Note to the moderator (optional)

Visible only to the moderator. Helps review go faster.