🧩Core Building Blocks·5 min read

API Gateways

The single front door that handles auth, routing, rate limiting, and more for your APIs.

An API gateway is the single front door for client traffic. Mobile apps, browsers, partners, and devices call one public API surface; the gateway authenticates, protects, routes, and shapes those requests before they reach internal services.

🔭Think of it like…

Think of a secure office tower. Visitors do not wander directly into any team's room. They enter through reception, show identification, receive a badge, get routed to the right floor, and may be stopped if the building is at capacity. The gateway is that reception desk for your backend.

The problem: every service should not be its own front door

In a service-oriented system, each backend could expose itself directly to the internet and implement TLS, authentication, logging, rate limits, request validation, and routing conventions. That design fails by duplication: every service becomes a security boundary, every team rebuilds the same middleware, and a bug in one public service can expose the whole platform.

Inconsistent policy: one service validates JWT audiences, another forgets, and a third has a stale allowlist.
Client coupling: clients must know which host and version belongs to every backend.
Operational sprawl: TLS certificates, WAF rules, request logs, and quota enforcement are scattered across many services.

The core idea

Centralize cross-cutting edge concerns at the gateway, but keep domain business logic in the services that own it. A gateway is a policy and routing layer, not a replacement for your application.

The single front door request path

A gateway usually sits behind DNS and a load balancer. It terminates client TLS, validates the request, applies policies, chooses an upstream, forwards the request, and returns a normalized response. It may be an appliance, a managed service, an Envoy/Nginx/Kong deployment, or code in your edge platform.

Clients call one gateway; the gateway applies policy and routes to services.

gateway request pipeline

request arrives at api.example.com
  -> terminate TLS and attach request id
  -> authenticate token / API key
  -> enforce rate limit and WAF rules
  -> validate route and transform headers/body if needed
  -> route /v1/orders/* to order-service
  -> collect upstream response, normalize errors, emit logs/metrics
  -> return response to client

Cross-cutting concerns gateways commonly handle

The gateway is attractive because many concerns apply to every API call regardless of which service ultimately owns the business operation.

Authentication and authorization: validate JWTs, API keys, mTLS client certificates, scopes, and tenant boundaries before traffic reaches services.
Rate limiting and quotas: protect backends and enforce plan limits per user, IP, API key, tenant, or route. See rate limiting for the algorithms behind this.
Routing and service discovery: map hosts, paths, methods, and versions to upstream services.
TLS termination: manage certificates and modern TLS settings in one hardened layer.
Request/response transformation: rewrite paths, headers, and payload shapes for compatibility or version migration.
Aggregation: combine several backend calls into one client response when that composition is truly an edge concern.
Observability: emit uniform access logs, traces, metrics, request IDs, and error envelopes.

Do not build a god gateway

A gateway should not become a giant service that owns pricing, checkout, feed ranking, and every domain rule. Keep business logic behind the gateway in services with clear ownership.

Gateway vs. reverse proxy vs. load balancer

These components overlap, but they are not the same abstraction. In real systems you may use all three: a cloud load balancer, an Envoy or Nginx reverse proxy, and an API gateway product or configuration layer.

Component	Primary job	Typical layer	Example features
Load balancer	Distribute traffic across healthy instances	L4/L7 infrastructure	Health checks, connection balancing, failover
Reverse proxy	Proxy client requests to upstream servers	L7 networking	TLS termination, caching, compression, path routing
API gateway	Manage public API policy and composition	Application edge	Auth, quotas, transformations, versioning, developer plans

A load balancer asks, "Which healthy instance should receive this connection?" A reverse proxy asks, "Which upstream should receive this HTTP request and how should it be proxied?" An API gateway asks, "Is this caller allowed to use this API, under which policy, and what client-facing contract should they see?"

Backend-for-Frontend (BFF) gateways

A Backend-for-Frontend is a gateway specialized for one client experience: web, iOS, Android, partner API, or admin console. It gives each client a convenient API shape without forcing backend services to know about every screen and device constraint.

BFF aggregation example

GET /mobile/home
  -> user-service: profile summary
  -> feed-service: first 20 cards
  -> notification-service: unread count
  -> experiment-service: feature flags

BFF returns one mobile-shaped payload optimized for the home screen.

Good fit: reducing mobile round trips, hiding backend service topology, or tailoring payloads for a specific UI.
Bad fit: duplicating core business rules that should live in domain services.

SPOF risk, latency, and production gotchas

Because every request enters through the gateway, it is a potentialsingle point of failure. Treat it like tier-zero infrastructure: redundant instances across zones, health checks, safe config rollout, rollback, overload protection, and strong observability.

High availability: run multiple gateway instances behind a load balancer and avoid regional singletons for global products.
Fail closed vs. fail open: decide what happens if auth, quota, or policy dependencies are unavailable. Security-sensitive routes usually fail closed.
Latency budget: every plugin and upstream policy check adds time. Cache JWKS keys, avoid synchronous heavy calls, and measure p95/p99 latency.
Config safety: a bad route rule can take down an API. Use staged rollout, validation, canaries, and fast rollback.
Header trust: services should only trust identity headers from the gateway on private networks or with signed context; never from arbitrary clients.

Defense in depth

Central auth at the gateway is useful, but critical services should still validate important authorization decisions locally. The gateway proves who the caller is; the service often decides whether that caller may mutate a specific resource.

Key takeaways

An API gateway is the single public front door that routes requests and centralizes edge policies for backend services.
Common gateway concerns include auth, rate limiting, routing, TLS termination, transformations, aggregation, observability, and error normalization.
Gateways overlap with reverse proxies and load balancers, but focus more on API policy, caller identity, quotas, and client-facing contracts.
Backend-for-Frontend gateways tailor APIs for specific clients, reducing round trips while keeping domain logic in owned services.
The gateway is a SPOF risk: run it redundantly, keep it lightweight, roll out config safely, and avoid turning it into a god service.

It gives one hardened edge layer for token validation, rejects bad traffic before it reaches services, and avoids inconsistent authentication bugs across teams. Services can still perform resource-specific authorization after receiving verified identity context.

A load balancer mainly distributes traffic across healthy instances. An API gateway also understands API policy: caller identity, quotas, route versions, transformations, aggregation, and developer-facing contracts.

All client traffic depends on it, so a gateway outage or bad config can take down every API. Run redundant instances behind load balancers, deploy across zones, canary config, monitor p95/p99 and errors, and maintain quick rollback.

Finished this lesson?

Mark it complete to track your progress through the workbook.