API Gateway Pattern

[!TIP] Interview Tip: If you have Microservices, you need an API Gateway. It solves “Cross-Cutting Concerns” (Auth, Logging, Throttling) so your individual services can focus on business logic.

In a monolithic architecture, the client talks directly to the server. In a microservices architecture, you might have 50 services. Does the client talk to all 50? No. You introduce a “Front Door”: the API Gateway.

1. Core Responsibilities

1.1 Request Routing

The gateway acts as a Reverse Proxy, routing requests to the appropriate microservice.

  • GET /users → User Service (10.0.0.1)
  • POST /checkout → Payment Service (10.0.0.5)

Interactive Visualizer: Routing Logic Simulator

Define simple path-based rules and test them. Type a path like /api/users/123.

Routing Rules (Config)
/api/users* → User Service
/api/orders* → Order Service
/api/pay* → Payment Service
* → 404 Not Found
Test Request
Waiting...
API Gateway
User Svc
Order Svc
Pay Svc

1.2 Authentication & Authorization (AuthN/AuthZ)

Instead of implementing JWT validation in every single microservice (DRY violation), you do it once at the Gateway.

  • The Gateway validates the token.
  • It passes the request to the backend with a header: X-User-ID: 123.

1.3 Rate Limiting

Prevents abuse (DDoS) or “Noisy Neighbor” issues. This is Rate Limiting.

Common Algorithms:

  1. Token Bucket: Allows bursts. (Tokens refill at rate R).
  2. Leaky Bucket: Smooths out traffic (constant outflow).
  3. Fixed Window: “100 reqs per minute”. Can suffer from spikes at window edges.

1.4 Circuit Breaking

If the “Payment Service” is down, the Gateway should stop sending requests to it immediately to prevent cascading failures. It “Trips the Circuit” and returns 503 Service Unavailable instantly.

Interactive Visualizer: Rate Limit & Circuit Breaker Arena

  • Token Bucket: Watch tokens refill. Bursts are allowed.
  • Circuit Breaker: Simulate a “Service Failure”. Watch the Gateway stop forwarding requests (Open State) and then try to recover (Half-Open).
Token Bucket
Available: 5
> System initialized. Mode: Token Bucket.

2. Advanced Patterns

2.1 Backend for Frontend (BFF)

A Mobile App has different needs (small screen, less data) than a Desktop Web App. Instead of one giant “One Size Fits All” API, create separate Gateways:

  • Mobile Gateway: Strips down responses, aggregates data to save battery.
  • Web Gateway: Returns full rich data. This is the BFF pattern.

BFF Architecture Diagram

Backend for Frontend (BFF) Pattern
Web App
Mobile App
Web BFF
Aggregates Full Data
Mobile BFF
Minifies JSON
Shared Microservices
User Service
Payment Service
Catalog Service

2.2 Case Study: Netflix API Gateway

Netflix was one of the pioneers of the BFF pattern.

  • Problem: Their TV UI needed different data than their iPhone UI. A generic API was too chatty (too many requests) or too heavy (too much data).
  • Solution: They built Zuul (now typically replaced by GraphQL Federation or similar).
  • Aggregation:
    1. Client requests GET /homepage.
    2. Gateway calls 5 services in parallel: (Recommendations, Continue Watching, Top 10, My List, New Releases).
    3. Gateway stitches them into one JSON response.
    4. Client receives 1 response. (Latency reduced significantly).

3. Observability: The RED Method

Since all traffic flows through the Gateway, it is the perfect place to measure system health. We use the RED Method:

  1. Rate: Number of requests per second.
  2. Errors: Number of failed requests per second.
  3. Duration: How long each request takes (Latency).

[!NOTE] Tracing ID The Gateway injects a X-Trace-ID header into every incoming request. This ID is passed down to every microservice. If a request fails deep in the stack (e.g., Database), you can search your logs for that ID and see exactly what path the request took.

4. API Gateway vs Service Mesh

A common point of confusion. When do you use which?

Feature API Gateway Service Mesh (e.g., Istio)
Location Edge (Entry point) Internal (Sidecar proxy)
Traffic Type North-South (Client → Server) East-West (Service → Service)
Focus Auth, Rate Limiting, Composition Retries, mTLS, Circuit Breaking
User External Clients Internal Services

Deep Dive: Sidecar Pattern

In a Service Mesh, every microservice has a tiny “Sidecar” container running next to it (like Envoy).

  • Service A doesn’t talk to Service B directly.
  • Service A talks to Sidecar A.
  • Sidecar A talks to Sidecar B.
  • Sidecar B talks to Service B.

This allows you to upgrade encryption (mTLS) or add retry logic without changing a single line of application code.

Best Practice: Use Both. The Gateway handles external traffic, and the Mesh handles internal communication.

5. Summary

  • API Gateway is the single entry point for all clients.
  • It handles Auth, Rate Limiting, SSL, and Routing.
  • Use the BFF Pattern to tailor APIs for different clients (Mobile vs Web).
  • Service Mesh handles internal (East-West) traffic.
  • Popular tools: Kong, Zuul, AWS API Gateway, Nginx.

You have completed Module 03! Review the key concepts in the Module Review before moving on.