Skip to main content
Architecture & Engineering

Horizontal Scaling

Horizontal scaling adds more machines to handle load, rather than making one machine bigger. It is the approach that scales without an upper bound and tolerates individual failures, provided the application is stateless enough that any instance can serve any request.

The alternative, vertical scaling, means moving to a larger instance. It is simpler and requires no application changes, which makes it the right first move — but every provider has a largest instance, and a single machine remains a single point of failure regardless of its size.

Horizontal scaling has a prerequisite that is easy to miss until it bites: instances must not hold state that other instances need. Sessions, uploaded files and in-process caches all have to move to shared services first. The database usually becomes the next bottleneck, which is where read replicas, connection pooling and caching enter.

Codazz builds this in production — Performance & Scaling.

FAQ

Horizontal Scaling
FAQ.

Common questions about horizontal scaling.

Ask Us Anything

Vertically, usually. Moving to a bigger instance requires no application changes and often buys enough headroom to remove the immediate pressure. Horizontal scaling is the durable answer but demands statelessness, shared session storage and a database that can take the added connections — work worth doing deliberately rather than during an incident.

Related terms

Load Balancing

Load balancing distributes incoming requests across multiple servers so no single instance becomes a bottleneck, and so the failure of one instance does not take the service down.

Caching

Caching stores the result of an expensive operation so subsequent requests can reuse it instead of recomputing it.

Containerization

Containerization packages an application together with its dependencies, libraries and configuration into a single image that runs identically on any machine with a container runtime.

Browse the full glossary →