API Gateway

An API gateway is a single entry point that sits in front of a collection of backend services and handles the concerns every one of them would otherwise have to duplicate: authentication, rate limiting, request routing, and response aggregation. Instead of a mobile client knowing about (and directly calling) a dozen individual services, it talks to one gateway, and the gateway figures out where each request actually needs to go.

It's the same layered idea as Load Balancing, one level up the stack: a load balancer distributes requests across identical copies of one service, while a gateway routes requests across different services based on what's actually being asked for. A real system typically has both — a gateway deciding which service handles a request, and a load balancer behind it spreading that traffic across that service's instances.

Gateway vs. reverse proxy vs. load balancer

These three terms get used loosely, but they sit on a spectrum of increasing intelligence, and it's worth being precise about the difference in an interview:

	Operates on	Primary job
Reverse proxy	Any traffic	Hides backend topology from the client
Load balancer	Requests to one logical service	Spreads load across identical instances
API gateway	API requests specifically	Routes by endpoint, plus cross-cutting concerns (auth, rate limits, transformation)

An API gateway is a reverse proxy, functionally — it's just a reverse proxy that's specifically aware of API semantics (routes, methods, payloads) rather than being a generic content-agnostic forwarder. This is the same Layer 4 vs. Layer 7 tradeoff that shows up in load balancing: more awareness of what's actually being requested unlocks smarter routing, at the cost of more work done per request.

System Design Lab

What a gateway centralizes

Every one of these could technically be implemented inside each individual service — but doing that means writing (and maintaining, and auditing) the same logic N times, once per service. Centralizing it in the gateway means it's implemented once:

• Authentication and authorization — verify a token or API key before a request ever reaches a backend service, so individual services can trust that anything reaching them has already been checked.
• Rate limiting — enforce per-client request quotas in one place; see Rate Limiting for the algorithms this actually runs on.
• Request routing — map an external-facing path to whichever internal service actually owns it, letting services be split, merged, or renamed internally without external clients noticing.
• Response aggregation — combine calls to multiple backend services into a single response, sparing a mobile client (often on a slow, metered connection) from making several round trips itself.
• Protocol translation — expose a single consistent protocol externally while backend services use whatever's convenient internally (e.g. gRPC between services, plain REST at the edge).

The tradeoff: a gateway is also a new single point of failure

Centralizing all of this in one place is exactly what makes it powerful, and exactly what makes it risky: every request now flows through the gateway, so if it goes down, every service behind it becomes unreachable even if all of them are individually healthy — the textbook definition of a Single Point of Failure. Production gateways are deployed the same way any other critical component is: multiple instances behind their own load balancer, with health checks and failover, not as one box.

The gateway also becomes an obvious place to add resilience patterns like a circuit breaker — since every downstream call already flows through it, it's a natural point to detect a failing service and stop sending it traffic before the failure cascades back to every client.

Why this matters in an interview

Any design with more than one or two backend services benefits from naming an API gateway explicitly, rather than leaving it implied. It's a concrete, checkable answer to "how does a client know where to send its requests" and "where does auth get enforced" — two questions that otherwise tend to get hand-waved. Just be ready to also name the tradeoff: it's now a critical path component that needs its own redundancy story.

Centralizing cross-cutting concerns in a gateway: pros and cons

Pros

• ✓Auth, rate limiting, and routing logic is implemented once instead of per-service
• ✓Backend services can be split, merged, or moved without external clients noticing
• ✓A single place to enforce policy, add observability, or introduce a circuit breaker

Cons

• ✕Becomes a new single point of failure unless deployed redundantly
• ✕Adds a network hop and processing latency to every request
• ✕Can become a bottleneck or a dumping ground for logic that belongs in individual services

Further Reading

• Microsoft Azure Architecture Center — API Gateway pattern — a practical breakdown of what a gateway should and shouldn't own in a microservices system.
• NGINX — What Is an API Gateway? — a concise overview of gateway responsibilities from a real implementation's perspective.