API Gateway

The Problem It Solves

 without a gateway, EVERY client integrates with EVERY service:

 [web]──────► auth, orders, inventory, recs, profile...
 [mobile]───► same, but wants smaller payloads...
 [partners]─► same, plus rate limits and keys...

 cross-cutting needs (auth, throttling, logging) get
 reimplemented per service. clients couple to internal
 topology. every refactor breaks somebody.

 API GATEWAY: single entry; route + enforce + shape:

 [clients]──►[GATEWAY]──►[orders] [inventory] [identity]
              │  auth ✓ rate-limit ✓ routing ✓ aggregation ✓

Gateway Responsibilities

 TYPICAL (own these here):
 □ AUTHENTICATION/authorization enforcement (token validation)
 □ RATE LIMITING/quota per client tier
 □ ROUTING to services (path/host based) + discovery integration
 □ TLS termination, compression, basic WAF integration
 □ RESPONSE SHAPING for clients (mobile gets slim payloads)
 □ REQUEST/CORRELATION-id injection (tracing seeds)

 OCCASIONALLY (carefully):
 - response AGGREGATION (compose profile+orders in one call)
   ⚠ custom aggregation code = gateway becomes a SERVICE —
   deployment cadence couples to features. keep generic.
 
 NEVER in the gateway:
 ✗ business logic / domain rules
 ✗ data storage of consequence
 it's a POLICY layer, not a product.

The Tradeoffs

Gain	Cost
central policy enforcement	extra hop (usually ms-class)
clients decouple from topology	gateway = critical path
one place for throttling/auth	config sprawl risk
simpler services	potential bottleneck to size

 critical-path status demands:
 HA deployment (multi-AZ, boring software),
 capacity headroom, and CHANGE DISCIPLINE
 (gateway configs deploy like production code — tested,
 staged — because they can take down everything at once).

Patterns Around the Gateway

 BACKEND FOR FRONTEND (BFF): gateways PER client-type
   (web-BFF, mobile-BFF) — own lesson, extends this one

 MICRO-GATEWAY: each domain/team runs its own edge
   (federated model) vs ONE central gateway — org scaling

 GATEWAY OFFLOADING examples that pay immediately:
   retry policies AT the edge (idempotent GETs)
   caching hot public responses
   request deduplication, body-size limits

Interview Framing

“Design the entry architecture for 20 microservices with web/mobile/partner clients” scored shape: gateway diagram with responsibility list (auth/ratelimit/routing/shaping), never-put-business-logic-here boundary stated, critical-path hardening noted (HA + change discipline), BFF variant proposed for mobile payload needs, aggregation-code warning included. Gateways appear in every microservices design — grading happens on whether yours stayed a door or became a second monolith.