API Gateway — The Front Door

The problem: without a gateway, every client speaks to every service

You run a microservices platform. Orders service on port 8001. Users service on 8002. Payments on 8003. Inventory on 8004. Notifications on 8005.

A mobile client needs to place an order. Without a gateway, the client must:

1. Call https://api.example.com:8001/orders to create the order
2. Call https://api.example.com:8003/payments to charge the card
3. Call https://api.example.com:8004/inventory to decrement stock
4. Call https://api.example.com:8005/notifications to send a confirmation email

Four problems:

1. Tight coupling. The client knows every service URL. Add a new service? Update every client.
2. No centralized auth. Each service must independently verify the JWT token — duplicated logic in 5 places.
3. No centralized rate limiting. A malicious client can hammer each service individually.
4. Chatty network. 4 round trips over cellular = 400-1200ms just in network overhead.

The solution: one front door

An API gateway sits between the client and all backend services. The client calls one URL — https://api.example.com/orders — and the gateway handles the rest.

The client makes one call. The gateway makes the backend calls. This is the gateway’s core value: decouple the client from the backend topology.

The six responsibilities

1. Routing — “where does this request go?”

/orders/**     → orders-service:8001
/users/**      → users-service:8002
/payments/**   → payments-service:8003
/inventory/**  → inventory-service:8004

The client never sees port numbers or service names. This is location transparency — the same concept as DNS, but at the application layer.

2. Authentication — “who are you?”

The gateway verifies the JWT token before any request reaches a backend service:

GET /orders/12345
Authorization: Bearer eyJhbG...

  ↓ Gateway verifies JWT signature + expiry
  ↓ Extracts user_id from claims
  ↓ Adds X-User-Id: 42 to the forward header
  ↓ Forwards to orders-service:8001

Backend services trust the X-User-Id header because only the gateway can set it (internal network is firewalled). Auth logic lives in one place, not five.

3. Rate limiting — “how fast can you send?”

Day 9’s token bucket algorithm runs inside the gateway. The gateway tracks per-client request counts (usually in Redis) and returns 429 Too Many Requests before the request hits the backend:

// Gateway rate limit middleware (conceptual)
if (redis.incr("rate:42") > 100) {
  return res.status(429).json({
    error: "Rate limit exceeded",
    retryAfter: 60
  });
}
// Forward to backend

The backend never sees the rejected request. The gateway is a shock absorber — it absorbs traffic spikes so the backend doesn’t have to.

4. Caching — “do I even need to ask?”

Day 2’s caching principle applies at the gateway too. If the response for GET /products/42 hasn’t changed, the gateway returns the cached response without calling the backend:

// Gateway cache check
const cached = redis.get("cache:GET:/products/42");
if (cached) {
  return res.json(cached)
    .set("X-Cache", "HIT");
}
// Cache miss → forward to backend → store response

5. Response aggregation — “one request, multiple services”

This is the gateway’s killer feature for mobile clients. Instead of the client making 4 calls, the client makes 1 call and the gateway fans out:

// Client sends ONE request:
GET /mobile/order-summary/12345

// Gateway internally calls:
  → orders-service:    GET /orders/12345
  → payments-service:  GET /payments?order=12345
  → inventory-service: GET /inventory?order=12345

// Gateway merges responses into one payload:
{
  "order":    { ... },
  "payment":  { ... },
  "inventory": { ... }
}

The mobile client makes 1 round trip instead of 4. Over a 200ms cellular connection, that’s 200ms instead of 800ms — a 4× latency reduction for the user.

6. Protocol translation — “speak the client’s language”

Backend services may use gRPC (Protocol Buffers over HTTP/2) for internal efficiency. External clients speak REST/JSON over HTTPS. The gateway translates:

Client (REST/JSON)
  → Gateway translates to gRPC
    → Backend (gRPC/Protobuf)

Response (Protobuf)
  → Gateway translates to JSON
    → Client

The connection: where every previous lesson lives

The API gateway is where Day 2 (caching), Day 7 (load balancing), Day 9 (rate limiting), and Day 14 (message queues) converge into a single layer. Each lesson taught a standalone cross-cutting concern. The gateway is where they all compose.

The tradeoff: the gateway is a single point of failure

Every request flows through the gateway. If it goes down, the entire platform goes down.

Benefit: One place for cross-cutting concerns. Cost: One place that can break everything.

The solution is the same pattern from Day 7: run multiple gateway instances behind a load balancer. The gateway itself is stateless — it stores rate limit counters and cache in Redis, not in local memory. So you can scale it horizontally.

This is the statelessness tradeoff from Day 7 applied to the gateway itself: stateless gateways + external state store = horizontal scalability + no single point of failure.

Real-world note: Kong, AWS API Gateway, NGINX, Envoy, and Traefik are all production-grade API gateways. They differ in implementation (Lua vs Go vs C) but all implement the same six responsibilities. The pattern matters more than the product.

What you should be able to do

• Name the six responsibilities of an API gateway (routing, auth, rate limiting, caching, aggregation, protocol translation).
• Explain why the gateway is a single point of failure and how statelessness + horizontal scaling solves it.
• Explain response aggregation: 1 client call → N backend calls → 1 merged response.
• Connect Day 2 (cache), Day 7 (LB), Day 9 (rate limit), Day 14 (message queue) as features that live inside the gateway.