Vertical vs Horizontal Scaling

Vertical scaling adds CPU and memory to one machine; horizontal scaling adds more machines behind a load balancer. Vertical is simple but limited and still a single point of failure; horizontal needs stateless design and data consistency care.

Scalability is the ability to handle more load by adding resources. There are two directions.

flowchart LR
  subgraph V["Vertical: scale up"]
    S1["4 vCPU / 16 GB"] -->|"resize"| S2["16 vCPU / 64 GB"]
  end
  subgraph H["Horizontal: scale out"]
    LB["Load balancer"] --> A["node 1"]
    LB --> B["node 2"]
    LB --> C["node 3"]
  end
  %% step S1: Vertical scaling gives one machine more CPU, memory or faster disks.
  %% step S2: It is simple — no code change — but has a hardware ceiling and usually a restart.
  %% step LB: Horizontal scaling adds machines; something must spread requests across them.
  %% step A: Each node must be able to serve any request, so state lives outside the nodes.

Comparison

	Vertical (up)	Horizontal (out)
How	Bigger instance	More instances
Code change	Usually none	App must be stateless; data must be shared or partitioned
Limit	Largest machine available	Very high (add nodes)
Availability	Still a single point of failure	Survives node loss
Downtime	Often a restart to resize	Add/remove without downtime
Needs	—	Load balancer, health checks, service discovery

Where each fits

Vertical: relational databases (primary node), caches, legacy apps that cannot run in parallel, quick fixes during an incident. Managed databases and caches mostly scale this way.
Horizontal: stateless web and API tiers, workers reading from a queue, distributed databases (Cassandra, DynamoDB), Kubernetes workloads.

Most real systems do both: scale the database up and add read replicas, scale the API out.

Disadvantages to remember

Vertical: hardware ceiling, cost grows faster than capacity at the top end, still one box.
Horizontal: needs a load balancer; risk of data inconsistency when instances keep local state or caches; more moving parts to monitor; distributed bugs (clock skew, partial failure).

Elasticity vs scalability

Scalability means you can grow. Elasticity means you grow and shrink automatically with demand, so you do not pay for peak capacity at 3 a.m. (lesson 4).

Traps: scaling the database up forever instead of fixing a missing index; scaling out an app that keeps sessions in memory; forgetting that a resize of a single database causes downtime unless it is Multi-AZ with failover.