api-gateway.js·4 scenarios
Single entry point: rate limiting, JWT auth, routing, API composition (BFF pattern)
The API Gateway is a single entry point that sits between external clients and a backend microservices architecture. Instead of clients calling individual services directly, all requests flow through the gateway, which handles cross-cutting concerns and routes requests to the appropriate service.
Without a gateway, every client must know the addresses of every service, implement its own authentication logic, handle service discovery, and manage retries and timeouts independently. The gateway centralizes these responsibilities into one component.
Real-world implementations:
Three types of external consumers connect to the gateway over HTTPS:
Incoming requests pass through a sequential pipeline of middleware components:
Three independently deployed services, each owning its own database (database-per-service pattern):
The gateway centralizes logic that would otherwise be duplicated across every service:
Authentication and Authorization: Token validation happens once at the gateway. Backend services receive pre-validated auth context (user ID, roles, scopes) and trust the gateway's decision. This eliminates redundant auth logic in every service.
Rate Limiting: Protects backend services from traffic spikes and abuse. Common algorithms include fixed window, sliding window, token bucket, and leaky bucket. Rate limits can be applied per client IP, per API key, or per user.
Routing: Path-based or header-based routing maps incoming URLs to backend services. The gateway also handles protocol translation (e.g., HTTPS from clients to gRPC toward services).
TLS Termination: The gateway terminates TLS connections from clients. Internal traffic between the gateway and backend services can use mutual TLS or plain-text within a trusted network boundary.
Logging and Observability: Centralized access logging, request tracing (correlation IDs), and metrics collection. Every request that enters or leaves the system is recorded in one place.
These three concepts are often conflated but serve different purposes:
API Gateway: A pure infrastructure component. It handles routing, auth, rate limiting, and TLS termination. It does not understand business logic or transform response payloads. It forwards requests to exactly one backend service per incoming request.
Backend-for-Frontend (BFF): A service layer tailored to a specific client type (mobile, web, TV). A mobile BFF might aggregate data from multiple backend services into a single optimized response, reshape payloads to minimize bandwidth, or filter fields the mobile client does not need. Each client type gets its own BFF.
API Composition: The act of fanning out a single client request to multiple backend services, waiting for all responses, and merging them into one payload. This is technically a BFF responsibility, not a pure gateway concern. However, many real-world gateways (Kong, AWS API Gateway, Spring Cloud Gateway) support composition via plugins or request transformers because the boundary between gateway and BFF is blurred in practice.
The script includes an API Composition scenario that demonstrates fan-out and merge. It is labeled as a BFF-style pattern to make the architectural distinction clear: a pure gateway would not do this, but many production gateways do.
Business Logic in the Gateway: The gateway should remain a thin routing and policy layer. Moving validation rules, data transformations, or orchestration logic into the gateway couples it to service internals and makes it a bottleneck for development teams.
Single Point of Failure: A gateway that is not deployed with high availability becomes a single point of failure for the entire system. Production gateways must run as a cluster behind a load balancer, with health checks, graceful failover, and zero-downtime deployments.
Monolithic Gateway: A single gateway that handles all routes for all services can become a deployment bottleneck. Large organizations sometimes use multiple gateways (or gateway instances with separate configurations) scoped to different domains or teams.
Response Transformation Creep: Starting with minor payload adjustments (renaming a field, filtering nulls) and gradually turning the gateway into a full data transformation layer. This belongs in a BFF or service layer.