API gateway vs load balancer

Both sit in front of your services and forward requests, which is why they get confused. They solve different problems, and many systems use both.

#Load balancer

A load balancer spreads traffic across a pool of identical backends and stops sending to unhealthy ones.

• L4 (transport): balances TCP or UDP connections by address and port. Fast and protocol-agnostic, but can't see HTTP — so long-lived HTTP/2 or gRPC connections can pin a client to one backend.
• L7 (application): terminates HTTP (and usually TLS), balances individual requests, and can route by host or path, add headers and retry.

Its concerns are distribution, health checks, TLS termination and connection draining.

#API gateway

An API gateway is an L7 proxy specialised for APIs. On top of routing, it handles cross-cutting API concerns so each service doesn't have to:

• authentication (validating JWTs or API keys) and coarse authorisation;
• rate limiting and quotas per client;
• request validation, size limits and CORS;
• routing by API version, and sometimes request or response transformation;
• consistent logging, metrics and tracing at the entry point.

#How they fit together

client → CDN/WAF → load balancer → API gateway (several instances) → services

A load balancer usually sits in front of the gateway instances, and internal load balancing (or a service mesh) spreads traffic from the gateway to each service.

#Pitfalls

• Putting business logic in the gateway. It becomes a shared bottleneck every team must change, and logic there is hard to test.
• Relying on the gateway for all authorisation. Services must still check that the authenticated user may touch the specific resource.
• A single gateway with no redundancy becomes a single point of failure for every API.

The DevSecOps roadmap covers both in depth, with configuration: see its load-balancing and API-gateway lessons.