The Front Door of Microservices
In a monolithic architecture, client requests go directly to the application. In a Microservices Architecture, your system might be split into 50+ different services. You cannot expect a mobile app to know the IP address of every service, handle authentication for each, and aggregate data from three different places.
The API Gateway is a server that acts as a single entry point into the system. It encapsulates the internal system architecture and provides an API that is tailored to each client.
1. Core Responsibilities
An API Gateway is more than just a reverse proxy. It handles cross-cutting concerns:
- Routing: The most basic function.
GET /users-> User Service.GET /orders-> Order Service. - Aggregation: A client needs user details AND their recent orders. The Gateway calls both services and combines the JSON into one response, saving the client from making 2 network calls (which is expensive on mobile).
- Protocol Translation: The outside world speaks HTTP/JSON. Internal microservices might use gRPC (binary, fast) or AMQP (messaging). The Gateway translates between them.
- Offloading: Moving functionality from individual services to the gateway:
- SSL Termination
- Authentication / Authorization
- Rate Limiting
- Caching
2. The BFF Pattern (Backend for Frontend)
A single API Gateway can become a bottleneck or a "God Class" that knows too much. The BFF Pattern suggests creating a separate gateway for each client interface.
- Mobile API Gateway: Small payloads, excludes heavy data to save battery.
- Web API Gateway: Rich payloads for desktop screens.
- Public Partner API: Strict rate limits and OAuth scope enforcement.
3. Rate Limiting Algorithms
Protecting your services from overuse or DDoS is critical. The Gateway typically implements this using Redis.
A. Token Bucket
- Imagine a bucket that holds tokens.
- Tokens stream in at rate per second.
- To make a request, a client must take a token.
- Pros: Allows bursts of traffic (up to bucket size).
- Cons: slightly complex to implement.
B. Leaky Bucket
- Requests enter a queue (bucket) and are processed at a constant rate.
- If the queue is full, new requests are dropped.
- Pros: Smoothes out traffic bursts exactly.
- Cons: Data burstiness is lost; valid traffic might be dropped during short bursts.
C. Fixed Window
- "100 requests per minute".
- Reset counter at 12:00, 12:01, etc.
- Problem: A client can send 100 requests at 11:59:59 and another 100 at 12:00:01. The server receives 200 requests in 2 seconds.
D. Sliding Window Log
- Keep a timestamp log of every request.
- Expensive memorywise but perfectly accurate.
4. Authentication & Security
The API Gateway is the Policy Enforcement Point.
- Authentication: The client sends a JWT or API Key. The Gateway validates the signature (Is this key valid?).
- Authorization: The Gateway checks scopes (Can this key access
/admin?). - Forwarding: If valid, the Gateway passes the request to the microservice. It often injects headers:
X-User-Id: 12345X-Role: AdminSo internal services don't need to re-validate tokens; they trust the Gateway.
5. Potential Drawbacks
While essential, API Gateways introduce risks:
- Single Point of Failure: If the Gateway acts up, the entire system is down. It requires high-availability setup (load balancers in front of redundant gateways).
- Latency: It adds an extra hop. However, 1 hop on a high-speed internal network is usually cheaper than multiple round-trips from the client to separate services.
- Complexity: Configuring routes and policies for hundreds of microservices is a management burden.
6. Popular Technologies
- Nginx / HAProxy: The raw, high-performance base layers. Hard to configure for complex logic.
- Kong: Built on Nginx, adds plugins for Auth, Rate Limiting, Logging. Very popular open-source choice.
- Amazon API Gateway: Serverless, scales infinitely, pays per request.
- Netflix Zuul: The original Java-based gateway from Netflix.
- GraphQL Servers (Apollo): Can act as an API Gateway, specifically excellent for Data Aggregation (Federation).
Summary
The API Gateway is the receptionist of your distributed system.
| Capability | Description |
|---|---|
| Routing | /api/v1/* -> Microservice |
| Security | SSL termination + JWT Validation |
| Traffic | Rate Limiting + Circuit Breaking |
| Translation | HTTP -> gRPC |
About ScaleWiki
ScaleWiki is an interactive educational platform dedicated to demystifying distributed systems, software architecture, and system design. Our mission is to provide high-quality, technically accurate resources for software engineers preparing for interviews or solving complex scaling challenges in production.
Read more about our Editorial Guidelines & Authorship.
Educational Disclaimer: The architectural patterns and system designs discussed in this article are based on common industry practices, technical whitepapers, and public engineering blogs. Actual implementations in enterprise environments may vary significantly based on specific product requirements, legacy constraints, and evolving technologies.
Related Articles
Circuit Breaker Pattern
A mechanism to prevent an application from repeatedly trying to execute an operation that's likely to fail.
System Design: Notification System
How to send millions of SMS, Email, and Push notifications reliably. Message Queues, Rate Limiting, and Retry policies.
Rate Limiting
Traffic control mechanism that limits the number of requests a user can make to prevent abuse, ensure fairness, and protect system resources from overload.