API Gateway

In a microservices system you might have 30 or 40 services, each owning a slice of the product: users, orders, payments, search, notifications. If every mobile app and browser had to know the address of each service, talk to each one directly, and re-implement login and rate limiting for all of them, the client would be a mess and every service would duplicate the same plumbing.

An API gateway fixes this by being one address that all clients call. The client sends a request to api.example.com, and the gateway decides which internal service should handle it. To the outside world there is one API. Behind the gateway there can be dozens of services on private network addresses that clients never see.

It is best to think of the gateway as a reverse proxy with extra responsibilities. A plain reverse proxy just forwards traffic. A gateway also checks who you are, whether you are allowed to make this call, how often you are allowed to make it, and sometimes reshapes the request and response along the way.

When a request arrives, the gateway runs it through an ordered chain of steps before any backend sees it. First it terminates TLS so the rest of the traffic inside your network can stay plain HTTP. Then it authenticates the caller, usually by validating a JWT or an API key, and rejects anything that fails with a 401 before it ever reaches a service.

Next it applies rate limiting and quotas, often backed by Redis counters, so one noisy client cannot flood your backend. Then it matches the request path and method against a route table. A rule like POST /orders forwards to the order service, while GET /search/* forwards to the search service. The gateway rewrites the path if needed and adds headers such as the resolved user id so the downstream service does not have to re-verify the token.

Some gateways also do request aggregation. A single call from a mobile home screen might fan out to the user, orders, and recommendations services in parallel, then the gateway stitches the three responses into one payload. This pattern, often called backend for frontend, cuts the number of round trips a slow mobile connection has to make.

Finally the gateway records metrics, latency, and status codes for every call, which gives you one place to see the health of the whole API instead of scraping logs from 40 services.

Reach for a gateway once you have more than a handful of services and more than one type of client. The payoff is real: auth, rate limiting, TLS, and logging live in one place instead of being copied into every service, and you can change a routing rule or block an abusive client without redeploying anything downstream.

The cost is that the gateway is now a single point of failure and a potential bottleneck. If it goes down, every API call goes down with it, so you run it as multiple replicas behind a load balancer and keep its logic thin. Every request also pays a small extra hop in latency, usually a few milliseconds, which is almost always worth it but is not free.

The other risk is the fat gateway. It is tempting to push business logic into the gateway because it is a convenient choke point. Resist that. Keep it focused on routing, security, and traffic shaping. Business rules belong in the services. A gateway stuffed with domain logic becomes a deployment bottleneck that every team has to coordinate around.

Picture a food delivery app. The phone makes one request to api.delivery.com/checkout with a bearer token. The gateway terminates TLS, validates the token against the auth service, and confirms the user has not exceeded 100 requests per minute.

It then routes the call to the order service, which creates the order, and the gateway also calls the payment service to authorize the card. If payment fails the gateway returns a clean 402 to the phone. The phone never learned the addresses of the order or payment services, never handled token verification itself, and made a single network call instead of three.

If the company later splits the order service into separate cart and order-history services, only the gateway route table changes. The mobile app keeps calling the same /checkout URL and never notices the refactor.