Part 6 · 2 chapters · ~12 min
Service Discovery and API Gateways
DNS and Kubernetes Services, registries such as Consul and Eureka with client-side balancing, health-based removal, discovery through a mesh, and API gateways (Kong, cloud gateways, Envoy Gateway) for authentication, rate limiting, routing and the north-south boundary.
8
Finding healthy instances
gRPC and HTTP/2 hold long-lived connections, so DNS-based balancing (per connection) can pin all traffic from one client to one pod. Fixes: client-side balancing with DNS re-resolution, a headless Service plus a gRPC balancer, or a mesh.
SERVICE DISCOVERY
how service A finds a healthy instance of service B
swipe the figure sideways, or tap expand for full screen
1/5
the problem
Instances come and go with deploys, scaling and failures. Hard-coded addresses break immediately. Service A needs a name that always resolves to healthy instances.
addresses change constantlycall names, not IPs
9
API gateways
| gateway job | why centralise it |
|---|---|
| authentication (JWT validation, API keys, OAuth introspection) | one implementation, consistently enforced |
| rate limiting and quotas per client | protect every service the same way |
| routing and versioning (/v1, /v2, canary weights) | services move without clients noticing |
| request and response transformation, CORS | keep it out of service code |
| analytics and developer portal | partner APIs need keys, docs and usage reports |
Products: Kong (Nginx and Lua, plugins), Tyk, Apigee, AWS API Gateway, Envoy Gateway and other Envoy-based gateways. Keep business logic out of the gateway: it should route and protect, not decide.