API Gateway Pattern

Introduction

API Gateway is the single entry point for clients into microservices — routing, authentication, rate limiting, TLS termination, and request shaping. It's the structural Facade + Proxy at the network edge: clients see one API; services stay internal.

The story

15 microservices exposed directly to mobile — 15 endpoints, inconsistent auth, chatty calls. Kong gateway cut mobile request count 70%, unified auth, decoupled client releases from service rewrites.

The business problem

Direct client-to-service access duplicates cross-cutting policy and couples clients to topology:

• Chatty clients: mobile orchestrates many service calls per screen.
• Policy duplication: auth, rate limit, logging in every service.
• Topology leak: service split/rename breaks clients.
• Inconsistent TLS/CORS: per-team implementation drift.

The problem teams faced

API Gateway fits when:

• Multiple microservices exposed to external clients.
• Cross-cutting policies must be uniform at edge.
• Clients should not know internal service topology.
• Rate limiting and auth centralized for security.

Understanding the topic

Intent: Single entry that routes to backing services with shared cross-cutting policies.

• Gateway — Kong, AWS API Gateway, Spring Cloud Gateway.
• Routes — path/host → upstream service.
• Plugins/filters — auth, rate limit, transform, log.
• Not BFF — gateway is generic infra; BFF is client-specific aggregation.

Internal architecture

Gateway routing:

Clients → API Gateway (Kong / AWS API GW)
              ├─ /orders/*   → order-service
              ├─ /catalog/*  → catalog-service
              └─ /users/*    → user-service

Plugins: jwt-auth, rate-limiting, request-transformer, prometheus

Visual explanation

Three diagrams cover gateway role, vs BFF, and policy centralization:

Informative example

Before / after — direct service access to gateway:

// ❌ Mobile calls 15 services — auth duplicated everywhere
fetch("https://orders.internal/api/...")
fetch("https://catalog.internal/api/...")

// ✅ Single gateway entry — policies once
fetch("https://api.example.com/v1/orders", {
  headers: { Authorization: `Bearer ${token}` }  // validated at gateway
})
// Gateway routes to order-service on private network

Execution workflow

Real-world use

Kong, AWS API Gateway, Azure APIM, Apigee, Spring Cloud Gateway, NGINX as edge gateway.

Production case study

Mobile 15-service exposure:

• Before: 15 direct endpoints; inconsistent auth.
• Decision: Kong gateway; services internal only.
• Outcome: mobile request count −70%; unified auth.

Trade-offs

• Pro: centralized policy; stable public API; hides topology.
• Con: single point of failure — scale and HA gateway.
• Con: can become god-gateway with business logic — resist.

Decision framework

• Use with microservices and external clients.
• Gateway for generic policies; BFF for client-specific shapes.
• Avoid business logic in gateway — route and policy only.

Best practices

• Services not publicly reachable — gateway only entry.
• Rate limit per client/API key at gateway.
• Public API versioning at gateway paths.

Anti-patterns to avoid

• God-gateway with checkout business rules.
• Gateway + BFF merged into one unmaintainable layer.
• Every service still validates JWT differently behind gateway.

Common mistakes

• Gateway outage takes all APIs down — multi-AZ HA required.
• Latency hop — budget in SLO.

Debugging tips

• Gateway access logs with upstream status — isolate route vs service failure.

Optimization strategies

• Cache GET responses at gateway for public read-heavy paths.

Common misconceptions

• Gateway ≠ BFF. Gateway shared; BFF per client type.
• Structural Facade + Proxy from GoF at network scale.

Advanced interview questions

Summary

You can place API Gateway at the edge, centralize policies, and distinguish from BFF. Tell the 15-service mobile story — if you can do that, you own API Gateway.