API Gateways: One Front Door for Many Services

An API gateway is the single entry point for a system made of many services. It reads each request's path and sends it to the service that owns it, and on the way it applies the rules every call needs, such as checking who the caller is and how many requests they may make. Each of those rules is then written once, at the gateway, instead of in every service.

What it does on each request. Authentication checks the caller's token and rejects a call without a valid one. A rate limit caps how many requests one caller may make in a period, such as 100 a minute, and refuses the rest. Routing sends /orders/... to the orders service and /users/... to the users service. Many gateways also log every call and turn errors into one consistent shape.

Why it helps. Without a gateway, each of six services checks tokens and counts requests in its own way, and the mobile app must know six addresses. With one, the app knows one address, and a fix to the token check is made in one place. Services can move or split behind the gateway without the app changing.

What it costs. Every call passes through it, so it adds a hop and must be as available as the whole system; a gateway with no spare is a single point of failure. Logic that belongs to one service, such as checking that an order is valid, does not belong in the gateway, or the gateway grows into a second application nobody owns.

Where you meet it. Amazon API Gateway, Kong, and NGINX configured with routing rules all play the part. A system with one service rarely needs a gateway; a load balancer or reverse proxy does the job.

So reach for an API gateway when many services share one set of callers: the rules every call needs are written once, at the door.