API Gateways

Updated June 3, 2026
M
Magic Magnets Team
8 min read

When Netflix moved from a monolith to microservices, they had a problem. Their mobile clients needed to talk to dozens of different backend services — a user service, a content catalog, a recommendations engine, a billing service. Asking the iOS app to make 15 separate API calls and stitch the responses together was a nightmare. The solution was an API gateway.

What an API Gateway Does

An API gateway is a server that acts as the single entry point for all client requests. Instead of clients communicating directly with backend services, they send requests to the gateway, which figures out where to forward them.

Think of it as the concierge desk at a large hotel. You don't wander through the building looking for housekeeping or the restaurant directly. You call the front desk and they route you to the right person.

At the simplest level, an API gateway does request routing: it receives requests on a single public address and forwards them to the appropriate internal service based on the URL path, headers, or other request attributes.

But in practice, gateways do a lot more.

algobase.dev
An API gateway is the single entry point for all client traffic. Instead of the iOS app tracking the addresses of a User Service, Catalog Service, and Billing Service separately (and knowing which to call), it sends everything to one address. The gateway routes requests to the right internal service based on URL path, host header, or other attributes. Internal service addresses can change, new services can be added, and the client configuration never needs to change. This is exactly what Netflix built to handle their mobile clients needing data from dozens of backend services.
1 / 1

Single entry point — all client requests hit the gateway, which routes to backend services

Core Features of an API Gateway

Authentication and Authorization

The gateway is the perfect place to verify that incoming requests are legitimate before they ever reach your backend services. Instead of implementing auth logic in every microservice, you centralize it at the gateway.

Common patterns:

  • Validate a JWT token in the Authorization header
  • Check an API key against a database
  • Delegate to an OAuth provider (verify the token with Auth0 or Cognito)

If the token is invalid, the gateway returns 401 Unauthorized immediately — your backend services never see the request.

Quiz Time

When an API gateway handles authentication, what happens to a request with an invalid JWT token?

Rate Limiting

The gateway enforces limits on how many requests a client can make in a given time window. Without this, a single misbehaving client (or a DDoS attempt) can saturate your backends.

A gateway can enforce limits at multiple granularities: per-IP (e.g. 100 requests/minute per address), per-user (e.g. 1000 requests/hour per authenticated user), and per-endpoint (a tighter limit on /v1/videos/render than on /v1/health).

When a client exceeds their limit, the gateway returns 429 Too Many Requests with a Retry-After header.

Quiz Time

When a client exceeds the rate limit enforced by an API gateway, the gateway returns HTTP 429.

SSL Termination

HTTPS traffic is encrypted. Before your backend services can read the request, someone has to decrypt it. Doing this on every service is wasteful — each service would need a TLS certificate, and the CPU cost of encryption/decryption would multiply across the fleet.

Instead, the gateway terminates SSL: it receives encrypted HTTPS traffic from clients, decrypts it, and forwards plain HTTP internally. Your internal network traffic stays within a controlled environment (typically a VPC), so the lack of encryption internally is acceptable.

This also means TLS certificate management is centralized — you renew one certificate at the gateway rather than certificates on 50 services.

Quiz Time

Why does an API gateway terminate SSL instead of passing encrypted traffic directly to backend services?

Request Logging and Observability

Every request that enters your system passes through the gateway, making it the ideal place to capture observability data:

  • Request/response logs with timestamps, latency, status codes
  • Distributed trace IDs (injected into request headers and propagated through the call chain)
  • Metrics aggregation for dashboards and alerts

Without a gateway, you'd have to instrument every service independently to get a complete picture of system behavior.

Routing and Load Balancing

Gateways can route requests to different backend services based on the request path (/api/users/* to the User Service, /api/payments/* to the Payment Service), the host header (api.myapp.com to production, staging-api.myapp.com to staging), arbitrary headers (e.g. X-Feature-Flag: new-checkout for A/B testing), or weighted routing that splits a percentage of traffic to a canary deployment.

Many gateways also do basic load balancing across multiple instances of the same service, though dedicated load balancers (like AWS ALB) often sit in front of the gateway itself.

Request/Response Transformation

Gateways can modify requests in flight: they can add headers before forwarding (injecting the user ID decoded from the JWT), strip sensitive headers before they reach the backend, transform request formats (JSON to XML for a legacy internal service), and aggregate responses from multiple backend calls into a single response — a pattern known as the Backend for Frontend (BFF).

algobase.dev
The real value of an API gateway is centralizing cross-cutting concerns. SSL termination: the gateway decrypts HTTPS traffic from clients, so backend services only handle plain HTTP — one certificate to manage instead of one per service. Rate limiting: a misbehaving client gets a 429 at the gateway before consuming any backend resources. Authentication: JWTs are validated at the edge — invalid tokens never reach the backend. The gateway can also inject the decoded user ID into a request header, so downstream services don't need to re-parse the JWT. Kong, AWS API Gateway, and Nginx are common implementations. If your system has more than a few microservices, a gateway isn't optional.
1 / 1

Gateway cross-cutting concerns — auth, rate limiting, SSL termination, logging, routing in one layer

API Gateway vs Reverse Proxy

This distinction comes up in interviews and it's worth being precise.

A reverse proxy is a server that forwards client requests to one or more backends. It typically handles SSL termination and load balancing. Nginx and HAProxy in HTTP mode are reverse proxies.

An API gateway is a reverse proxy with higher-level features: it understands your API specifically, handles authentication, enforces rate limits, and provides observability designed for API traffic.

All API gateways are reverse proxies. Not all reverse proxies are API gateways.

The line is blurry in practice — Nginx with a bunch of plugins can function as a basic API gateway. The distinction is more about purpose and feature richness than a binary technical difference.

Quiz Time

All reverse proxies qualify as API gateways.

Real Products

AWS API Gateway

The managed AWS option. Deeply integrated with Lambda (you can invoke Lambda functions directly from route configurations), IAM, and Cognito. Supports REST and WebSocket APIs. Auto-scales to zero — you pay per request, not per hour.

The main downside is vendor lock-in and sometimes surprising latency overhead for high-frequency, low-latency API calls. It also has a steeper learning curve than its managed nature implies.

Kong

Open-source and enterprise API gateway built on top of Nginx/OpenResty. Kong's plugin architecture is its killer feature — you install plugins for rate limiting, auth, logging, and transforms, and they compose cleanly. It can run on-prem, on Kubernetes, or as a managed cloud service (Kong Konnect).

Kong is the go-to for teams that want gateway power without full AWS lock-in.

Apigee (Google Cloud)

Apigee is enterprise-grade API management — heavy features around API monetization, developer portals, and analytics. It's used by large enterprises that need to expose APIs to third-party developers at scale (think telcos, financial institutions). More complex than Kong or AWS API Gateway, and priced accordingly.

Nginx

With the right configuration and plugins (like the Nginx Plus rate limiting module), Nginx can serve as a capable API gateway. Many smaller teams use Nginx for gateway-like functionality without adopting a dedicated API gateway product. It's less feature-rich but has extremely predictable performance characteristics.

Quiz Time

Which API gateway product is known for a plugin architecture built on top of Nginx/OpenResty?

Summary

An API gateway is the front door to your microservices architecture. It centralizes cross-cutting concerns (auth, rate limiting, SSL termination, logging) so your individual backend services can focus on their actual domain logic. Auth at the gateway means one place to update security policies. Rate limiting at the gateway protects all services with a single config. SSL termination at the gateway simplifies certificate management across the fleet. Routing at the gateway decouples public URLs from internal service topology, so you can restructure your backends without touching client code.

If you're designing a system with more than a handful of microservices, an API gateway isn't optional — it's the thing that keeps client-side complexity manageable.

Rate Limiting

How helpful was this content?

Comments

0/2000

Sign in to join the discussion

Saved on this device only

Sign in to sync progress across devices