API Gateways

In a microservices architecture, a single client request often requires data from multiple independent backend services. If clients connect directly to each microservice, they must manage multiple network hostnames, handle complex authentication states, and coordinate API updates across different service teams.

An API Gateway resolves this complexity by acting as the single, centralized ingress point for all external client requests. The gateway exposes a unified public interface, intercepts all incoming traffic, executes a sequence of validation and security policies, and routes requests to appropriate internal microservices. This design acts as a specialized reverse proxy, isolating internal service changes from the public API contract.

---

Think of an API Gateway as the security desk and receptionist at the front entrance of a large corporate office building:

• Direct Service Connections are like a building without a front door. Visitors wander down random corridors, search for individual employee desks, ask for security badges, and negotiate entry routes. This model creates chaos and compromises building security.
• An API Gateway is like the reception desk in the front lobby. Every visitor must enter through the lobby. The receptionist terminates external access, checks the visitor's ID card (authentication), verifies they are allowed on the 4th floor (authorization), checks that they are not bringing in oversized bags (payload limits), and calls an internal escort to guide them along the correct path (reverse proxy routing).

---

The core function of an API Gateway is reverse proxying. The gateway maps incoming public HTTP request paths to internal microservice network endpoints.

For example, a gateway matches path patterns:

• https://api.company.com/v1/users is forwarded internally to http://user-service.internal:8080/users
• https://api.company.com/v1/orders is forwarded internally to http://order-service.internal:9090/orders

This translation layer decouples external clients from the internal network topology. If the company moves the order service to a new port or splits it into separate shipping and invoice services, the gateway updates its internal routing table. The public API client contract remains completely unchanged.

---

By centering all ingress traffic in a single system, the API Gateway unifies duties that would otherwise have to be re-implemented in every microservice:

• TLS Termination: The gateway handles the CPU-intensive cryptographic handshake for HTTPS connections. Internal microservices then communicate over plain HTTP within the secure private virtual network, reducing latency and simplifying certificate management.
• Authentication and Authorization: The gateway validates incoming JWTs or OAuth tokens. It extracts the authenticated user metadata and injects it into upstream request headers (e.g. X-User-Id), allowing internal microservices to assume request authenticity.
• API Versioning: The gateway can inspect headers (e.g. Accept: application/vnd.company.v2+json) or path prefixes to route requests to specific legacy or modern versions of microservices.

---

When a request arrives, the gateway executes a sequence of validation and enrichment steps known as a middleware chain:

1. Security Filters: The gateway inspects payloads to block SQL injection attacks, Cross-Site Scripting (XSS), and requests exceeding payload size limits. It also injects Cross-Origin Resource Sharing (CORS) headers to authorize browser requests.
2. Distributed Rate Limiting: The gateway tracks incoming traffic volumes (typically by Client IP or token identifier) using memory stores like Redis. It drops requests exceeding allowed quotas (returning 429 Too Many Requests) to prevent system degradation.
3. Tracing and Logging Context: The gateway generates a unique correlation identifier (e.g. X-Correlation-Id) for each request. It injects this ID into the HTTP headers forwarded to internal microservices, allowing logs across the entire microservice chain to be reconstructed during debugging.

---

Because the API Gateway acts as the single point of entry for all corporate traffic, restarting the gateway to apply configuration changes introduces unacceptable downtime.

Production gateways (such as Envoy, Kong, or Nginx with Lua extensions) decouple the control plane from the data plane. The gateway exposes a configuration API that updates routing tables, rate limits, and access rules in memory. The data plane applies these configuration updates dynamically at runtime, managing active client connections without dropping packets.

---

In many modern microservice environments, internal services communicate using high-performance protocols like gRPC or Protobuf over HTTP/2, which are difficult for web browsers to consume directly.

An API Gateway bridges this gap by performing protocol mapping. The gateway receives standard REST HTTP/1.1 requests (JSON payloads) from public clients, serializes the data into Protobuf format, and forwards it as a gRPC call to internal microservices. It then translates the internal gRPC response back to JSON before returning it to the client, combining internal performance with external accessibility.

---

As the primary entry point, the API Gateway is a single point of failure. If the gateway fails, the entire application is offline.

To ensure high availability:

• Horizontal Scalability: API Gateways are run as stateless instances behind global Layer 4 load balancers (such as AWS ALB or Cloudflare CDN).
• Circuit Breakers: If a downstream microservice (e.g. the payment service) slows down, the gateway's circuit breaker trips. The gateway stops sending requests to the failing service and returns a cached response or an immediate error, preventing the gateway from exhausting its thread pool.
• Retry and Timeout Policies: The gateway enforces strict socket read/write timeouts on upstream connections, failing fast rather than hanging, and retrying transient network errors safely.

---

• Envoy Proxy Architecture — A detailed look at how modern service proxies manage data and control planes.
• Microservices Patterns: External API Patterns — Chris Richardson's overview of the API Gateway and API Gateway Backends-for-Frontends (BFF) patterns.
• OWASP API Security Top 10 Cheat Sheet — Guidelines for implementing API Gateway security controls to prevent credential stuffing and resource injection.