API Gateway
A centralized entry point that routes client requests to backend microservices while handling authentication, rate limiting, and protocol translation.
An API Gateway is a server that acts as an entry point for all client requests to backend services. It sits between the client applications and the microservices or monolithic backend, abstracting the underlying architecture and simplifying client interactions. The primary functions of an API Gateway include request routing, request/response transformation, authentication and authorization, rate limiting, caching, logging, and monitoring. By centralizing these cross-cutting concerns, the gateway prevents them from being duplicated across multiple backend services, leading to cleaner, more maintainable code. Request routing directs incoming API calls to the appropriate backend service based on the request path, headers, or other criteria. Transformation allows the gateway to modify requests or responses, for example, by changing data formats (e.g., XML to JSON) or aggregating data from multiple services. Security is a critical aspect; the gateway can handle authentication (verifying the identity of the client) and authorization (determining if the client has permission to access the requested resource), often by integrating with identity providers or token validation services. Rate limiting protects backend services from being overwhelmed by too many requests, while caching can improve performance by serving frequently requested data directly from the gateway. This architectural pattern is particularly prevalent in microservices architectures, where it helps manage the complexity of numerous distributed services.
graph LR
Center["API Gateway"]:::main
Rel_api_development["api-development"]:::related -.-> Center
click Rel_api_development "/terms/api-development"
Rel_microservices["microservices"]:::related -.-> Center
click Rel_microservices "/terms/microservices"
Rel_load_balancer["load-balancer"]:::related -.-> Center
click Rel_load_balancer "/terms/load-balancer"
classDef main fill:#7c3aed,stroke:#8b5cf6,stroke-width:2px,color:white,font-weight:bold,rx:5,ry:5;
classDef pre fill:#0f172a,stroke:#3b82f6,color:#94a3b8,rx:5,ry:5;
classDef child fill:#0f172a,stroke:#10b981,color:#94a3b8,rx:5,ry:5;
classDef related fill:#0f172a,stroke:#8b5cf6,stroke-dasharray: 5 5,color:#94a3b8,rx:5,ry:5;
linkStyle default stroke:#4b5563,stroke-width:2px;
🧠 Knowledge Check
🧒 Explain Like I'm 5
An [API](/en/terms/api) [Gateway](/en/terms/gateway) is like a helpful receptionist for a big office building; it directs visitors (your app's requests) to the right department (backend service) and makes sure only authorized people get in, without the visitor needing to know the internal layout.
🤓 Expert Deep Dive
The API Gateway pattern addresses the challenges of managing distributed systems, particularly microservices, by providing a single, unified interface for clients. Key architectural considerations include the choice between a centralized gateway (single point of entry) versus decentralized (per-service or per-domain gateways). Centralized gateways simplify client interactions and enforce consistent policies but can become a bottleneck and single point of failure. Decentralized gateways offer better scalability and fault isolation but can lead to policy duplication. Common implementation patterns include the Backend For Frontend (BFF) pattern, where specialized gateways cater to the specific needs of different client types (e.g., mobile, web). The gateway's role in protocol translation (e.g., REST to gRPC) and request aggregation is crucial for decoupling clients from backend service evolution. Performance implications arise from the added network hop and processing overhead, necessitating efficient routing, caching, and potentially asynchronous processing. Security enforcement at the gateway level, such as JWT validation or OAuth 2.0 token introspection, is a critical security best practice.