An API Gateway is a server that acts as the single entry point for client requests to backend services. It handles routing, security, and cross-cutting concerns so individual services don't have to, making it a critical piece of modern distributed and microservices architectures.
An API Gateway sits between clients (browsers, mobile apps, third-party consumers) and your backend services, acting as a reverse proxy that forwards requests to the appropriate service. It consolidates multiple service endpoints behind one stable URL. Think of it as the front door to your entire backend system.
Without a gateway, every client would need to know the address of every individual service, and each service would have to independently implement authentication, rate limiting, and logging. A gateway centralizes these cross-cutting concerns, reducing duplication and giving you a single place to enforce policy. It also decouples your internal service topology from your public API surface, so you can refactor backends without breaking clients.
When a request arrives, the gateway first authenticates and authorizes it — often by validating a JWT or API key. It then applies policies such as rate limiting or request transformation before routing the call to the correct upstream service. The upstream response is returned to the client, potentially after further transformation like stripping internal headers or aggregating responses from multiple services.
Common features include SSL/TLS termination, load balancing, request/response transformation, caching, circuit breaking, and observability (logging, metrics, tracing). Many gateways also support protocol translation, such as converting a REST request into a gRPC call to an internal service. Popular implementations include Kong, AWS API Gateway, NGINX, Apigee, and Traefik.
An API Gateway serves all clients from one layer, while a Backend-for-Frontend (BFF) pattern uses separate gateways tailored to specific client types (mobile vs. web). A service mesh (e.g., Istio) handles service-to-service communication inside the cluster and complements, rather than replaces, an API Gateway at the edge. Understanding these distinctions prevents over-engineering or misuse of each tool.
Because all traffic flows through the gateway, it becomes a critical single point of failure and a potential performance bottleneck if not properly scaled and made highly available. Avoid putting heavy business logic in the gateway — keep it focused on infrastructure concerns and let services own domain logic. Always deploy your gateway in a redundant, horizontally scalable configuration with health checks and circuit breakers in front of upstreams.
© RM Full Stack & AI Engineer · All guides · Roadmaps · Open the app