Steven's Knowledge

API Gateway

The single entry point in front of your services - auth, routing, rate limiting, observability, and the edge of your platform

API Gateway

An API gateway is the single front door for traffic entering your platform. Every external request — from a browser, a mobile app, a partner system — hits the gateway first. The gateway authenticates the caller, applies rate limits, routes to the right backend, and emits observability signals. Backends never see the raw outside world.

Why Use One

Without a gatewayWith a gateway
Every service implements auth, rate limit, CORS, TLSCross-cutting concerns handled at the edge
Mobile / partner / web clients all hit different services directlyOne stable contract; backend changes don't leak
Per-service tokens scattered across the orgCentral token issuance and validation
TLS termination per serviceTerminate at the edge; mTLS inside
Per-service rate limiting (or none)Coordinated quotas
"Where did the 502 come from?"Edge logs are the single source of truth for traffic

Gateway vs Load Balancer vs Service Mesh

These three are easy to confuse — they overlap but solve different problems.

Load Balancer (L4/L7)API GatewayService Mesh
Traffic axisNorth-southNorth-southEast-west (service-to-service)
LayerL4 (TCP) or L7 (HTTP)L7 onlyL7
AuthUsually noneYes — JWT/OIDC/API keyService identity (mTLS)
Rate limitingCrude (LB-level)First-classPossible but not the focus
API-level featuresNoneSchema validation, transformsRetries, timeouts at transport layer
Best forSpreading load across replicasExposing services to the outsideSecuring & observing internal traffic

A typical big-platform layout uses all three — a cloud LB in front of an API gateway that fronts a meshed cluster.

Internet


 ┌────────┐
 │  LB    │   TLS terminate, L4 distribution
 └────┬───┘

 ┌────────────┐
 │ API GW     │   auth, rate limit, routing, transforms
 └────┬───────┘

 ┌─────────────────────────────────────┐
 │  Service Mesh (mTLS, retries, ...)  │
 │  ┌────┐  ┌────┐  ┌────┐             │
 │  │ A  │  │ B  │  │ C  │  ← services │
 │  └────┘  └────┘  └────┘             │
 └─────────────────────────────────────┘

The Players

ToolNotes
KongLua + Nginx (open-source); strong plugin ecosystem; commercial enterprise edition
Envoy / Envoy GatewayThe de-facto edge proxy in modern stacks; programmable; the basis of many other tools
TraefikAuto-discovery, K8s-native, great defaults; LB + gateway in one
NGINX / NGINX PlusBattle-tested; declarative config; K8s Ingress popular
HAProxyPure L4/L7 LB with edge features; very fast
ApigeeGoogle's managed API platform; enterprise-grade governance
AWS API GatewayTightly tied to AWS Lambda + REST/HTTP/WebSocket APIs
GCP API Gateway / Azure API ManagementCloud-managed equivalents
TykOpen-source; rich plugin model
Cloudflare Gateway / Fastly ComputeEdge-first; CDN integration; serverless edge functions

For Kubernetes, also consider Gateway API — the spec-driven successor to Ingress that any compliant controller (Envoy Gateway, Istio, Contour, NGINX) can implement.

Learning Path

What a Gateway Doesn't Do

A common trap is to put business logic in the gateway. Avoid:

  • Long-running orchestration
  • Cross-service joins / aggregation that look like another service
  • Custom business workflows
  • Stateful long sessions

The gateway is a policy enforcement and traffic control point, not a service. If your gateway has its own database, you've gone too far.

The smaller your gateway's config diff, the better. Big gateways with hundreds of bespoke transforms become fragile single points of failure. Push business logic back into services; keep the gateway dumb and fast.

On this page