API gateway: the front door of a microservice system

An API gateway is a server that sits in front of your backend services and is the single entry point for clients. Instead of a mobile app knowing the address of ten services, it talks to one.

What a gateway usually does

• Routing: /orders goes to the orders service, /users to the users service.
• Authentication and authorization: check the token once at the edge.
• Rate limiting and quotas per client.
• TLS termination: handle HTTPS in one place.
• Request and response shaping: change formats, compress, cache.
• Aggregation: combine several service calls into one response, which saves round trips for mobile clients.
• Observability: one place for logs, metrics and tracing IDs.

Gateway vs load balancer vs reverse proxy

They overlap. A load balancer spreads traffic across copies of one service. A reverse proxy forwards requests (Nginx). A gateway adds API-level features such as auth, quotas and versioning. Many products do all three.

The BFF pattern

A Backend for Frontend is a gateway built for one client type, for example one for the mobile app and one for the web app. Each returns exactly the data its client needs.

Risks

• Single point of failure and bottleneck. Run several instances behind a load balancer.
• Too much logic. If business rules creep into the gateway it becomes a hidden monolith. Keep it thin.
• Extra hop of latency. Small, but real.

Tools

Kong, NGINX, Envoy, AWS API Gateway, Cloudflare and others.

Takeaway: use a gateway for cross-cutting concerns (auth, limits, routing), keep business logic in services, and run it redundantly.

---

Part 13 of 15 in the System Design series. Previous: Message queues: why systems use them and how they fail.