API Gateway

A reverse proxy that sits in front of your microservices and centralizes cross-cutting concerns: authentication, authorization, rate-limiting, request transformation, routing, logging. Clients talk to the gateway; the gateway talks to the actual services.

In a microservices world, every backend would otherwise have to re-implement auth, rate-limiting, request logging, TLS termination, and CORS, and do it inconsistently. The gateway centralizes that boilerplate so services can focus on business logic.

Inbound requests hit the gateway. It validates the JWT/API key, checks the rate-limit counter, rewrites the URL if needed, attaches user context, then forwards to the right backend (often via service discovery). The response flows back through the gateway, which can do response transformations or logging on the way out.

• One place to enforce auth + rate-limit policies across the entire backend
• Backend services can stay 'dumb' about who's calling them
• Easy to add new cross-cutting concerns (canary routing, A/B tests) without touching every service

• Extra hop that adds latency to every request
• If it goes down, everything goes down (must be HA)
• Can become a god-object if too much logic accumulates here

• URL Shortener →

  Auth + rate-limit + routing to read vs write services

• Netflix →

  Zuul handles every control-plane API call; video bytes bypass it via the CDN

• Payment Gateway →

  TLS termination, audit logging, API-key auth all in the gateway

• Treat the gateway as infrastructure, not business logic. Routing rules are fine; complex business logic belongs in services.
• Latency-sensitive paths (video bytes, websocket frames) should bypass the gateway; the gateway is for control plane.
• Run multiple instances behind a load balancer. A single-instance gateway is the most expensive SPOF in your architecture.