API Gateway and Service Discovery

The problem clients face

With dozens of services, a browser or mobile app cannot know the address of each one, and it should not deal with cross-cutting concerns like authentication on every call. An API gateway solves this by being the single entry point.

What the gateway does

• Routing: forwards /orders/** to the Orders service, /users/** to the Users service.
• Authentication: validates the token once, so services trust incoming requests.
• Cross-cutting concerns: rate limiting, logging, TLS termination, CORS.
• Aggregation: can combine several service calls into one client response.

Client -> API Gateway -> { Orders, Users, Billing }

Service discovery

Service instances come and go – they scale up, restart, and get new IP addresses. Hard-coding addresses is impossible, so services register themselves in a service registry (such as Eureka or Consul), and callers look up healthy instances by name.

// instead of a fixed IP:
GET http://192.168.1.24:8080/api/users/42
// look up by logical name:
GET http://users-service/api/users/42   // registry resolves it

Load balancing

Because the registry returns several instances of a service, the caller (or the gateway) balances requests across them. In Kubernetes, a built-in Service object provides both discovery and load balancing, so an explicit registry is often unnecessary.

Key points

• An API gateway is the single entry point that routes and secures client requests.
• It centralises authentication, rate limiting, TLS and can aggregate responses.
• A service registry lets services find each other by name as instances change.
• Discovery plus multiple instances enables load balancing; Kubernetes provides both.