API Gateway and Service Discovery

How do clients find services, and how do services reach each other? Two patterns answer that: the API Gateway and Service Discovery.

Direct access breaks down fast: a client talking to 10 services must know every address, handle security per service, and track ones that come and go.

An API Gateway is the single entry point — the front desk for your microservices. Clients send every request to it instead of to individual services.

An API Gateway does far more than route: it handles authentication, rate limiting, and caching, offloading cross-cutting concerns from your services.

A request through the Gateway: the app calls it, the Gateway authenticates the user, routes to the right service, and relays the response back.

Services start, stop, and move, so their addresses change. Service Discovery lets services find each other's location without hardcoding any addresses.

At the core sits the Service Registry: a live database of every active instance's location. Services register on startup and deregister on shutdown.

In client-side discovery, the client queries the registry itself, then load-balances across the instances and calls one directly. The client knows where to look.

In server-side discovery, the client just hits a router that queries the registry and forwards the request. The client never touches the registry.

You've learned about API Gateways and Service Discovery. Let's see if you can distinguish their primary roles.

You covered two essential patterns: an API Gateway gives clients one secure entry point, and Service Discovery lets services find each other dynamically.