*Horizontal vs Vertical Scaling

September 15, 2025

Definitions

  • Vertical (scale‑up): add CPU/RAM to one machine.
  • Horizontal (scale‑out): add more machines and distribute load/state.

Vertical scaling

  • Simpler ops, no distributed systems complexity.
  • Hard limits and single point of failure without redundancy.
  • Great for databases that don't shard easily and moderate traffic.

Horizontal scaling

  • Requires stateless services or explicit partitioning/replication for state.
  • Higher resilience; near‑linear capacity growth when well‑designed.

Laws and ceilings

  • Amdahl: speedup limited by the serial fraction.
  • Gustafson: scale problem size with processors to keep efficiency.

Cost model

  • Big boxes are expensive; commodity nodes + LB often cheaper beyond a point.
  • Consider licensing tied to cores/sockets.

Data layer considerations

  • Caches, read replicas, partitioned tables, message queues for async work.

Code: stateless session (JWT)

// language-typescript
import jwt from 'jsonwebtoken'
export function issueSession(user) {
  return jwt.sign({ sub: user.id }, process.env.JWT_SECRET, { expiresIn: '1h' })
}

Code: worker pool sizing

// language-typescript
const cores = require('os').cpus().length
const poolSize = Math.max(cores * 2, 8) // IO‑bound heuristic

Migration playbook

  1. Scale up until diminishing returns; profile hotspots.
  2. Externalize state (sessions/files) and add a load balancer.
  3. Introduce a cache and read replicas; cap concurrency per dependency.
  4. Partition hot data or split services by bounded context.

Analogy

Scaling up is upgrading a single elevator. Scaling out is adding more elevators and a lobby that directs people efficiently.

FAQ

  • Do I need Kubernetes? Not to scale out. Start with simple LBs and autoscaling; add orchestration when complexity warrants it.
  • Is vertical dead? No—databases love RAM/IOPS; do both where it fits.

Vertical (scale-up)

  • Add CPU/RAM on a single instance.
  • Operational simplicity, but hardware ceiling and single point of failure.
  • Good for databases that don't scale horizontally well or low traffic applications.

Horizontal (scale-out)

  • Add nodes; requires statelessness and partitions (sharding) or replication.
  • Increased resilience, linear costs, network/data complexity.

Costs and Amdahl's Law

Scale-out gains depend on the parallelizable fraction. Serial sections dominate overall latency.

Recommendation

Start vertically, design for horizontal; extract server state (cache, DB, blob) and automate discovery/health checks.