API Gateway: Features, Examples and Reverse Proxy vs Gateway

An API gateway is the single entry point into a microservices system. It sits between clients and backend services, receives every request and routes it to the right service, while handling the concerns every service would otherwise repeat: authentication, rate limiting, monitoring and more. Think of it as a reverse proxy with extra features built for API management. A plain reverse proxy (Nginx, HAProxy) does the forwarding, TLS and load balancing; the gateway adds the API-specific layer on top.

The problem it solves

Picture a mobile app talking directly to 12 microservices: users, orders, payments, inventory, notifications and more. Without a gateway:

• The client knows too much. It must know every service's address and handle different protocols and data formats. The app juggles 12 endpoints, 12 authentication schemes and 12 retry strategies, and every backend change risks breaking it.
• Screens are slow. Loading the home screen means calling users, products, recommendations, cart and notifications. Five sequential HTTP calls from a phone add up to around 500 ms.
• Nothing protects the services. A malicious client sends 10,000 requests a second to the order service, which has no rate limiting. It crashes, and real customers can't place orders.
• Cross-cutting work is duplicated. Every service implements its own authentication, authorization, rate limiting, logging and monitoring.

That is tight coupling between clients and services: the system becomes hard to maintain and hard to change. The gateway fixes it by giving clients one endpoint. It routes each request, authenticates uniformly, enforces rate limits and can combine several backend calls into one.

Key features

1. Request routing

The gateway sends each request to the right backend based on the URL path, HTTP method, headers or query parameters. Routing by version or header also enables gradual rollouts, for example sending /v2/orders to a new service or 5% of traffic to a canary.

GET  /api/users/123   → User service
GET  /api/orders/456  → Order service
POST /api/payments    → Payment service

2. Load balancing

Gateways spread requests over the instances of each service. With three order-service instances, requests go round-robin: instance 1, 2, 3, 1… See load balancing for the algorithms.

3. Authentication and authorization

Doing this once, at the edge, means no service has to reimplement it. This is where a gateway earns its place in most designs.

• Authentication: verify the caller's identity (JWTs, API keys, OAuth tokens) before forwarding, then pass the verified identity to services in a header. See authentication.
• Authorization: check the caller may use this API at all (for example, does the token have the right scope?). Fine-grained, per-object checks still belong in the service that owns the data. See authorization.

4. Rate limiting and throttling

Protect backends from overload and abuse by rejecting excess traffic with 429 Too Many Requests before it reaches them. See rate limiting.

Per user:            100 requests / minute
Per IP:              1,000 requests / hour
Per service (search): 10,000 requests / hour

5. Protocol translation

Convert between protocols and formats: HTTP to gRPC, REST to GraphQL, JSON to XML, and long-lived WebSocket connections. A common case: backend services talk to each other over fast, typed gRPC, but clients want a plain REST API.

Backend teams get efficient gRPC internally, clients get a familiar REST API, and each team can pick the best protocol without affecting anyone else. See REST vs gRPC vs GraphQL.

6. Request and response transformation

The gateway can rewrite requests and responses in flight, translating between what clients send and expect and what services need and return: adding headers, reshaping responses, combining data from several services, and stripping sensitive fields.

// Client request
GET /api/users/123

// The gateway forwards it with internal headers added
{
  url: "/internal/users/123",
  headers: {
    "Authorization": "Bearer internal-service-token",
    "X-Request-ID": "req-12345",          // for tracing
    "X-User-Role": "customer"             // taken from the client's verified JWT
  }
}

// What the backend returns
{ "id": 123, "name": "John Doe", "email": "john@example.com",
  "internalId": "EMP-567890", "salary": 95000, "ssn": "123-45-6789", "role": "customer" }

// What the gateway returns to the client (sensitive fields removed)
{ "id": 123, "name": "John Doe", "email": "john@example.com", "role": "customer" }

This adds authentication without touching backend code, keeps internal and sensitive data (salaries, SSNs, internal IDs) from leaking, injects metadata for tracing and monitoring, and standardizes response formats across services. In a well-run system services shouldn't return sensitive fields in the first place, but the gateway is a useful second line of defense.

7. Request aggregation

The app sends one request, GET /home. The gateway calls the user, product and cart services in parallel, merges their responses into one JSON payload and returns it. One round trip from the phone replaces three or five, which matters most on slow mobile networks. This is a fan-out/fan-in at the edge.

8. Caching

Cache responses that change rarely, for example product details for 5 minutes, so repeated requests never reach the backend. See caching.

9. Monitoring and analytics

Since all traffic passes through it, the gateway is the natural place to record request logs, response times, error rates and usage per client, and to inject a trace ID at the edge. That makes monitoring and debugging much simpler. See observability.

Reverse proxy vs API gateway

• A forward proxy acts for clients: a company proxy that all employee traffic goes through. The server doesn't know which client is behind it.
• A reverse proxy acts for servers: clients talk to it as if it were the server, and it chooses a backend. It handles TLS termination, load balancing, caching and compression, buffering of slow clients, and hides the backend topology (often with a web application firewall).
• An API gateway is a reverse proxy plus API management: authentication, per-client rate limits and quotas, routing to many services, protocol translation, transformation and aggregation.

Popular API gateways

Backend for frontend (BFF)

Different clients want differently shaped data: a phone screen needs less than a desktop page. A BFF is a gateway-like layer per client type (web BFF, mobile BFF), owned by that client's team, which aggregates and tailors backend calls. It keeps a single general-purpose gateway from accumulating every client's special cases.

Pitfalls

• Too much logic in the gateway. Business rules in the gateway create a distributed monolith that every team has to change. Keep it to cross-cutting concerns.
• Single point of failure. Run the gateway as a redundant, horizontally scaled tier across zones.
• Extra hop. Every request pays a little latency; keep the gateway's own work cheap (cache token-verification keys, avoid a remote call per request where possible).
• Gateway vs service mesh. A gateway handles north-south traffic (clients into the system); a service mesh handles east-west traffic (service to service).

API gateways in system design interviews

Interviews focus on the business requirements and scale, so the gateway is usually drawn as one box at the edge that routes requests to the microservices and handles authentication, authorization, rate limiting and monitoring. You rarely need more than that. If the interviewer asks you to go deeper, use the features above: routing rules, where tokens are verified, rate-limit keys, aggregation and how the gateway itself scales.