API Gateway

In a Nutshell

An API gateway is a single entry point that sits in front of your backend services and handles all the cross-cutting concerns that every API needs — authentication, rate limiting, routing, request/response transformation, and more. Instead of each microservice reimplementing auth, throttling, and logging, the gateway does it once, at the edge, for everyone. It's the front door to your API: clients talk only to the gateway, which validates and shapes their requests before routing them to the right internal service, then relays the response back. In a microservices world, the API gateway is what keeps the individual services simple and the client's life sane.

How It Actually Works

The Problems It Solves

Without a gateway, a microservices system forces two bad choices onto clients and services:

Without a gateway:
  Client must know EVERY service's address and call each directly.
  EACH service must implement auth, rate limiting, logging, TLS...
  → duplicated cross-cutting logic + clients coupled to internals. 💥

With a gateway:
  Client talks to ONE endpoint.
  Cross-cutting concerns implemented ONCE at the gateway.
  Services stay simple and focus on business logic. ✅

Core Responsibilities

Function	What It Does
Routing	Map incoming paths to the right backend service (/orders → order-service)
Authentication/Authorization	Validate tokens/API keys once; reject unauthorized requests early
Rate limiting & throttling	Protect backends from abuse and overload (see Rate Limiting)
Request/response transformation	Reshape payloads, translate protocols (REST ↔ gRPC)
Aggregation	Combine responses from multiple services into one
TLS termination	Decrypt HTTPS at the edge
Caching	Cache common responses to offload backends
Observability	Central logging, metrics, tracing, correlation IDs

Gateway vs Load Balancer vs Reverse Proxy

These overlap (see Load Balancer & Reverse Proxy), differing in application-awareness:

	Load Balancer	Reverse Proxy	API Gateway
Focus	Distribute traffic	Edge functions + LB	API management
Awareness	L4/L7	HTTP	Deep API/business awareness
Adds	Health checks	TLS, cache, routing	Auth, rate limits, aggregation, versioning, transformation

An API gateway is the most application-aware — it understands your API's structure, not just HTTP.

API Composition / Aggregation

A powerful gateway pattern: a single client request that would otherwise require many round trips is fulfilled by the gateway calling several services and merging the results.

Client: GET /dashboard
  Gateway fans out in parallel:
    → user-service      (profile)
    → orders-service    (recent orders)
    → recommendations   (suggestions)
  Gateway merges the three responses → one payload → client
  Client made ONE request instead of three. Fewer round trips,
  especially valuable over slow mobile networks.

The Backend-for-Frontend (BFF) Pattern

Different clients need different shapes of data. Rather than one bloated gateway, you can run a gateway per client type — a "Backend for Frontend":

Mobile app  → Mobile BFF   (lean payloads, battery-aware)
Web app     → Web BFF      (richer data)
Partners    → Public API GW (strict rate limits, versioning)

Each BFF tailors auth, aggregation, and payload shape to its client, without compromising the others.

The Trade-off: A Critical Chokepoint

The gateway's strength — everything flows through it — is also its risk: it's a potential single point of failure and bottleneck. Mitigate by running it as a horizontally-scaled, highly-available fleet (multiple instances behind a load balancer), keeping its logic lean, and avoiding turning it into a monolith of business logic. It should handle cross-cutting concerns, not become a god-service.

Seeing It in Action

Scenario: An API gateway fronting an e-commerce microservices backend.

Request: GET /api/v2/dashboard   (from the mobile app, with a JWT)

Gateway pipeline (executed in order):
  1. TLS termination            → decrypt HTTPS
  2. Authentication             → validate JWT; extract user_id;
                                  reject with 401 if invalid (early exit)
  3. Rate limiting              → check user's quota (e.g., 1000 req/hr);
                                  return 429 + Retry-After if exceeded
  4. Routing + versioning       → /v2/ → v2 handlers
  5. Aggregation (fan-out):
        → user-service:    GET /users/{id}
        → order-service:   GET /orders?user={id}&limit=5
        → rec-service:     GET /recommendations?user={id}
     (called in parallel; gateway waits for all)
  6. Transformation             → merge into ONE mobile-optimized payload,
                                  stripping fields the mobile app doesn't need
  7. Observability              → log request, emit metrics, propagate
                                  trace ID to all downstream calls
  8. Response                   → single JSON payload → client

What the backend services get to ignore:
  auth, rate limiting, TLS, cross-service aggregation, client-specific
  shaping — all handled at the gateway. Each service just serves its
  own resource over plain HTTP on the private network.

Why this is the standard microservices front door: the mobile client makes one authenticated request and gets one tailored payload, despite three services being involved — a huge win over slow mobile networks. Every service stays focused on its single responsibility because the gateway owns the cross-cutting concerns. And the internal topology (how many services, where they live) is completely hidden from clients, so the backend can evolve freely. The cost is that the gateway must be run as a resilient, scaled-out fleet — but that's a well-understood, worthwhile trade.

Interview Questions

1. Q: What is an API gateway and what problems does it solve? Hint: A single entry point in front of backend services that handles cross-cutting concerns — auth, rate limiting, routing, transformation, aggregation, TLS, caching, observability. It solves duplication (services would each reimplement these) and client coupling (clients would need to know every service). Services stay simple and focused; clients talk to one endpoint; internal topology is hidden.

2. Q: How does an API gateway differ from a load balancer and a reverse proxy? Hint: Increasing application-awareness. A load balancer distributes traffic (L4/L7) with health checks. A reverse proxy adds edge functions (TLS, caching, routing). An API gateway is the most API-aware — it understands your API's structure and adds auth, rate limiting, versioning, request aggregation, and protocol/payload transformation. They overlap and one product may play multiple roles.

3. Q: What is API composition/aggregation and why is it valuable? Hint: The gateway fulfills one client request by calling several backend services (often in parallel) and merging their responses into a single payload. It reduces client round trips — especially valuable on slow mobile networks — and keeps aggregation logic out of clients and individual services. Example: /dashboard fanning out to user, orders, and recommendations services.

4. Q: What is the Backend-for-Frontend (BFF) pattern? Hint: Running a separate gateway per client type (mobile, web, partners), each tailoring auth, aggregation, and payload shape to that client's needs — lean payloads for mobile, richer data for web, strict versioning/limits for public partners. It avoids one bloated general-purpose gateway and lets each client's needs evolve independently.

5. Q: What's the main risk of an API gateway and how do you mitigate it? Hint: It's a chokepoint — a potential single point of failure and performance bottleneck since all traffic flows through it. Mitigate by running it as a horizontally-scaled, highly-available fleet behind a load balancer, keeping its logic lean, and restricting it to cross-cutting concerns rather than letting it accumulate business logic and become a god-service/monolith.

References

• Microservices.io: API Gateway pattern — the canonical pattern and BFF
• AWS API Gateway — a managed gateway's features
• Kong / Envoy gateway docs — production API gateways

Dive Deeper

• Netflix: The evolution of the Netflix API gateway (Zuul) — a gateway at massive scale
• Backends for Frontends (Sam Newman) — the BFF pattern in depth
• Building Microservices by Sam Newman — gateways in microservice architecture