LOAD BALANCER
ONE ENTRY POINT.
MULTIPLE SERVERS.
A routing layer that distributes incoming traffic across healthy backend instances, handles failures, and gives the system room to scale without changing the way clients connect.
NEED ONE FOR YOUR TRAFFIC?
BOOK A MEETINGTHE SCALING PROBLEM
ONE SERVER CAN GROW.
IT CAN'T GROW FOREVER.
The simplest way to handle more traffic is to make the server bigger. More CPU, more memory, more capacity. But eventually that machine reaches a physical ceiling — and the next step is no longer making one server bigger, but running multiple servers together.
01 / VERTICAL SCALING
SCALE UP
THE MACHINE HAS A CEILING.
FINITE CPU · FINITE MEMORY · SINGLE INSTANCE
02 / HORIZONTAL SCALING
SCALE OUT
WHO DECIDES WHERE EACH REQUEST GOES?
03 / LOAD BALANCER
STABLE ENTRY POINT
HORIZONTAL SCALING ADDS CAPACITY.
THE LOAD BALANCER DISTRIBUTES IT.
Instead of pushing one machine further, horizontal scaling spreads the workload across multiple instances. The load balancer becomes the stable entry point, distributing incoming requests across the available servers.
WHEN THE SYSTEM GROWS OUTWARD, TRAFFIC NEEDS A WAY THROUGH.
TRAFFIC ROUTING
EVERY REQUEST NEEDS SOMEWHERE TO GO.
The load balancer sits between the client and the server pool. Every incoming request reaches it first, where the routing logic determines which healthy instance should handle the request.
01 / ARRIVE
ANSWER FIRST
The sender is answered the moment its webhook arrives. Delivery continues in the background.
02 / DECIDE
ELIGIBILITY → SCORE
Stale workers sit out. The lowest score serves first.
03 / DELIVER
FORWARD → ACK
The worker answers the balancer — never the original sender.
- Request arrives: a webhook reaches the load balancer.
- The load balancer receives it: verify, normalize, classify, route.
- Available instances are evaluated against the eligibility gates.
- Routing decision: lowest load score among the eligible serves first.
- Request forwarded: the normalized event is delivered to the selected worker.
- Server responds: the worker returns a correlated ack to the balancer.
The worker answers the balancer — never the original sender. The sender was already answered the moment its webhook arrived: 200 ACCEPTED, while delivery continues in the background.
THE DECISION
THE ROUTE ISN'T RANDOM.
Every delivery starts with eligibility, not preference. Nodes that are disabled, missing, stale, unhealthy, or over their configured CPU or memory ceiling are set aside with a recorded reason. The survivors are scored — CPU times its weight plus memory times its weight — and the lowest score serves first. Ties keep configured order; nodes without telemetry rank last.
HEALTH-AWARE ROUTING
ROUTING ONLY WORKS WHEN THE BACKEND IS ELIGIBLE.
- SERVER 01✓ HEALTHY
- SERVER 02✕ STALE
- SERVER 03✓ HEALTHY
A server can be reachable without being eligible. When a worker stops reporting, its heartbeat goes stale and it drops out of the pool on the very next delivery — no probing required. When it resumes fresh, healthy heartbeats, it becomes eligible again.
FAILURE EXAMPLE
NORMAL
LB ├── S01 ✓
LB ├── S02 ✓
LB └── S03 ✓
SERVER FAILURE
LB ├── S01 ✓
LB ├── S02 ✕
LB └── S03 ✓
ACTIVE POOL
LB ├── S01 ✓
LB └── S03 ✓
If a delivery attempt fails mid-flight, the balancer moves to the next eligible candidate until the deadline — except a 400 from a worker, which is never retried elsewhere, because the request itself was bad. If every candidate is exhausted, an optional fallback tier gets its chance.
THE LOAD BALANCER IS THE DECISION POINT.
Clients keep talking to one stable entry point while the infrastructure behind it decides where each request should go. Next: what the balancer watches to make that call — and what happens when an instance disappears from the pool.
CUSTOM INFRASTRUCTURE
GET A LOAD BALANCER
BUILT FOR YOUR TRAFFIC.
Custom routing, health checks, and failover — designed around your servers, not a generic template. Let's build yours.
BOOK A MEETING