API Gateway

Table of Contents

🔴 P0 — appears in nearly every system design; the single entry point pattern

Problem #

Clients shouldn’t need to know the internal topology of your microservices. Without a gateway, clients must discover, authenticate with, and manage connections to dozens of services independently.

Mechanism #

External Clients
      ↓
┌─────────────────────────┐
│      API Gateway         │  ← single entry point
│  ┌───────────────────┐  │
│  │ Auth / Rate Limit  │  │  ← cross-cutting concerns
│  │ Routing            │  │
│  │ Request Transform  │  │
│  │ Response Aggregate │  │
│  └───────────────────┘  │
└─────┬──────┬──────┬─────┘
      ↓      ↓      ↓
  Service  Service  Service
    A        B        C

What the gateway handles #

Authentication & authorisation: validate tokens before requests hit services
Rate limiting: enforce per-client or per-endpoint limits
Request routing: map external URLs to internal service endpoints
Protocol translation: REST externally → gRPC internally (see also: Web-gRPC Proxy)
Response aggregation: combine responses from multiple services into one
SSL termination: handle TLS at the edge

Key Trade-offs #

Dimension	Benefit	Risk
Single entry	Simplified client integration	Single point of failure
Cross-cutting	Centralised auth, logging, metrics	Gateway becomes a god service
Abstraction	Internal topology hidden from clients	Extra hop adds latency
Coupling	Services decoupled from clients	Gateway team becomes bottleneck

Gateway vs Service Mesh #

Gateway: north-south traffic (external → internal). Handles client-facing concerns.
Service mesh (e.g. Istio): east-west traffic (internal ↔ internal). Handles service-to-service concerns (mTLS, retries, observability).
They’re complementary, not competing.

Instinct #

Keep the gateway thin. It should handle cross-cutting concerns (auth, rate limiting, routing) but never contain business logic. The moment you put business logic in the gateway, it becomes a monolith bottleneck. If you need per-client API customisation, use BFF instead — see also: Backend for Frontend.

Framing #

The disambiguation test:

Junior: “API Gateway and Service Registry… aren’t they the same thing?”
Senior: “No, API Gateway is for external clients, Service Registry is for internal services to find each other.”
Staff: “They solve different problems at different layers. The key insight: gateway is on the critical path for every client request; registry is off-path after the initial lookup. This affects their operational requirements and failure modes differently.”

API Gateway vs Service Registry #

These are often conflated but solve different problems at different layers:

Dimension	API Gateway	Service Registry
Purpose	Route external requests to backends	Track where services are and their health
Audience	External clients	Internal services (service-to-service)
Location	Edge of the system	Internal infrastructure
Critical path	On-path for every external request	Off-path after initial lookup
Failure mode	All external traffic blocked	New discovery fails; cached connections persist
Examples	Kong, AWS API Gateway, NGINX	Consul, Eureka, etcd, Kubernetes DNS

Relationship: Gateway can use Registry for dynamic routing. They’re independent systems solving different problems.

INTERVIEW: Rarely need to elaborate on API gateway internals. Just handwave it as a layer of indirection:

We’ll put an API gateway in front for auth, rate-limiting, and routing to internal services.

References #

microservices.io: API Gateway Pattern — Chris Richardson
Netflix Zuul 2 — API Gateway at Netflix scale

DDIA 2e Reference #

Chapter 4: Service-oriented architecture, API boundaries