API Gateway Pattern
The “Front Door” of Microservices
In a microservices architecture, a single client request (like “Show me my dashboard”) might require data from ten different services. If the client had to call each service individually, the performance would be terrible, and the security surface would be enormous.
An API Gateway acts as a single entry point for all clients. It sits between the client and the internal services, acting as a reverse proxy that orchestrates the communication.
Core Responsibilities
- Request Routing: Forwards requests to the appropriate service based on the path (e.g.,
/api/v1/orders->Order Service). - Request Aggregation: Fans out a single client request to multiple downstream services, combines their results, and returns a single JSON object.
- Cross-Cutting Concerns: Centralizes authentication, SSL termination, rate limiting, and logging in one place.
- Protocol Translation: Can translate between modern external protocols (HTTP/2, REST) and internal high-performance protocols (gRPC, SignalR).
Architecture Styles
1. The Single Gateway
One gateway for all clients (Mobile, Web, 3rd party).
- Cons: Can become a “bottleneck” where all teams are fighting to change the same config file.
2. Backend for Frontend (BFF)
Specific gateways for specific client types.
- Example: A
Mobile-Gatewaythat returns smaller payloads and aWeb-Gatewaythat returns rich data. - Pros: Perfectly optimized for the consumer’s needs.
Technical Comparison
| Feature | Without Gateway | With Gateway |
|---|---|---|
| Network Calls | Multiple (slow) | Single (fast) |
| Security | Each service exposed | Only gateway exposed |
| Complexity | High (Client-side) | Low (Gateway-side) |
| Latency | Network overhead per call | Single extra hop |
Practice Exercise
Design the flow for a “Product Detail” page request that requires data from Catalog, Inventory, and Review services.
Answer
The Aggregation Workflow
- Client sends
GET /products/123. - Gateway intercepts the call and verifies the JWT token.
- Fan-out: The Gateway sends three parallel requests:
internal/catalog/123internal/inventory/123internal/reviews/123
- Wait: The Gateway waits for the slowest service to respond or hits a timeout.
- Merge:
{ "product": { "name": "Laptop", "price": 999 }, "stock": 42, "reviews": [{ "user": "Nhon", "rating": 5 }] } - Response: Client receives the merged object in a single HTTP trip.
Why This Architecture Works
- Performance: For mobile users on high-latency 4G/5G networks, reducing three trips to one is a massive UX win.
- Security: Internal services can stay on a private network with no public IP. Only the Gateway is exposed to the internet.
- Flexibility: You can rename an internal service or change its protocol (e.g., switch
Inventoryfrom REST to gRPC), and the client doesn’t need to change a single line of code.
Summary
The API Gateway is the central nervous system of a distributed architecture. While it introduces a single point of failure (which must be mitigated with high availability), the benefits in security, performance, and developer productivity make it a non-negotiable component of any production-grade microservices system.