API Gateway

What it is

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.

The problem it solves

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.

How it works

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.

Why use it

• 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

What it costs you

• 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

Where it shows up in our architectures

• 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

Gotchas

• 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.