การกระจายโหลดและการค้นหาบริการ

When one server cannot handle all traffic, you run many copies. A load balancer sits in front and spreads incoming requests across these instances.

This is the backbone of horizontal scaling for SaaS backends.

Clients connect to a single address. The load balancer accepts the request and forwards it to one of the backend servers, then relays the response back.

To the client, the cluster looks like one powerful server.

The simplest algorithm is round robin: requests are handed to servers in rotation. Each server gets an equal share.

Least connections routes each new request to the server currently handling the fewest active connections.

This adapts better than round robin when requests have uneven durations.

Load balancers operate at different network layers:

• Layer 4 (transport) — routes by IP and port, very fast
• Layer 7 (application) — inspects HTTP, can route by URL path or headers

Layer 7 enables smart routing like sending /api to one pool and /static to another.

A load balancer must avoid sending traffic to dead servers. It runs periodic health checks against each instance.

A common pattern is a /health endpoint returning 200 OK when the app is ready.

Some apps store session state in server memory. Sticky sessions pin a client to the same server so their session persists.

Better practice: keep servers stateless and store sessions in a shared store, so any server can handle any request.

In dynamic environments, servers come and go constantly. Service discovery keeps an up-to-date registry of which instances exist and are healthy.

Tools like Consul, etcd, or Kubernetes services automate this.

Two models:

• Server-side — clients hit a load balancer that consults the registry
• Client-side — clients query the registry directly and pick an instance themselves

Server-side is simpler; client-side reduces a network hop.

Load balancers pair with autoscaling: when traffic rises, new instances spin up, register with discovery, and the balancer starts routing to them automatically.

When traffic drops, instances are removed gracefully after draining connections.

Before shutting down an instance, the balancer should stop sending new requests but let existing ones finish. This is connection draining.

It prevents dropped requests during deployments and scale-down events.

Test your load balancing knowledge.

You learned how SaaS backends distribute traffic:

• Load balancers with round robin and least connections
• Layer 4 vs Layer 7 routing and health checks
• Stateless design, service discovery, and graceful draining

Together these let a backend scale horizontally and survive failures.