API Gateway
In a microservices architecture, clients should not need to know about individual service addresses.
Quick answer: API Gateway
API Gateway is covered here as a practical system design concept. In a microservices architecture, clients should not need to know about individual service addresses. Use it to understand the APIs idea, where it appears in production systems, and how to discuss it clearly in interviews.
Focus on the problem being solved, the main design choice, the failure mode, and the tradeoff you would defend in front of a senior engineer. This page is part of the DosiBridge system design knowledge graph, so it links related concepts, interview problems, tradeoffs, and references instead of leaving the topic isolated.
An API gateway is the single entry point for all client requests to your backend services. It handles cross-cutting concerns — authentication, rate limiting, request routing, protocol translation, and response aggregation — so individual services don't duplicate that logic. Kong, AWS API Gateway, and Netflix Zuul are common implementations.
| Aspect | Details |
|---|---|
| What it is | Application-layer entry point that manages, secures, and routes all API traffic |
| When to use | Microservices with external clients; multi-platform APIs needing auth, rate limiting, or versioning at the edge |
| When NOT to use | Internal service-to-service calls (use service mesh instead); monolith with a single API |
| Real-world example | Netflix Zuul routes all external API calls; AWS API Gateway + Lambda powers serverless architectures |
| Interview tip | Distinguish from reverse proxy — API gateway understands API semantics: routes, consumers, quotas, versions |
| Common mistake | Routing internal traffic through the gateway — adds unnecessary latency and coupling |
| Key tradeoff | Centralized control and consistency vs. single point of failure; 10-30ms added latency per request |
Why This Matters
In a microservices architecture, clients should not need to know about individual service addresses. The API gateway provides a unified interface, simplifies client code, and centralizes security and monitoring.
The Building Blocks
- Request routing: Routes /api/users to User Service, /api/orders to Order Service.
- Authentication: Validates JWT tokens or API keys before forwarding to backend services.
- Rate limiting: Prevents abuse by limiting requests per client/IP.
- Request/response transformation: Converts between protocols (HTTP ↔ gRPC), aggregates responses from multiple services.
- Circuit breaking: Stops forwarding requests to a failing backend service, returning cached or default responses instead.
Under the Hood
All client requests go to the API gateway first. The gateway authenticates the caller, checks rate limits, routes the request to the correct backend service, transforms the response if needed, and returns it to the client. This decouples clients from the service topology.
For BFF (Backend for Frontend) patterns, you might have separate gateways for web, mobile, and third-party API clients, each optimized for their specific needs.
How Companies Actually Do This
Netflix Zuul/Spring Cloud Gateway: Routes billions of requests daily across hundreds of microservices.
AWS API Gateway: Managed service that handles authentication, throttling, and caching for serverless architectures.
Kong: Open-source API gateway used by companies like Nasdaq and Zillow for request routing and plugin-based extensibility.
Common Pitfalls
- Putting business logic in the gateway — it should only handle cross-cutting concerns
- Not scaling the gateway — it handles ALL traffic and can become a bottleneck
- Not implementing circuit breaking — a failing backend can overwhelm the gateway
Interview Questions Worth Practicing
- What is an API gateway and why is it needed?
- What are the responsibilities of an API gateway?
- What is the BFF pattern?
- How do you prevent the API gateway from becoming a single point of failure?
The Tradeoffs
- Centralization vs Decentralization: A gateway simplifies clients but creates a central bottleneck.
- Latency: Every request passes through an extra network hop.
- Complexity: The gateway itself must be highly available, scalable, and well-monitored.
How to Explain This in an Interview
Here is how I would explain API Gateway in a system design interview:
An API gateway is the front door for all external API traffic. It sits between clients and your microservices, handling everything common across services: authentication (validate JWT tokens once, not in every service), rate limiting (per-consumer quotas), request routing (/v1/users goes to user-service, /v2/users to the new version), and response aggregation (mobile clients get one call instead of five). The key interview distinction: a load balancer distributes traffic, a reverse proxy handles TLS and caching, but an API gateway understands your API contract — routes, consumers, versions, and policies. In a .NET stack, you would use Ocelot or YARP as an API gateway in front of your ASP.NET Core microservices.
Related Topics
Original DosiBridge notes for API Gateway
This section is written specifically for this page, not copied from a general system-design checklist. The useful way to study API Gateway is to connect the concept to an integration boundary where bad contracts become customer-facing outages. That framing changes the design discussion from definitions to operating choices.
What makes this topic distinct
- Contract Evolution: For API Gateway, decide the contract evolution before choosing tools; otherwise the design looks clean but fails when api changes.
- Idempotency: For API Gateway, decide the idempotency before choosing tools; otherwise the design looks clean but fails when gateway changes.
- Pagination: For API Gateway, decide the pagination before choosing tools; otherwise the design looks clean but fails when api changes.
- Error Shape: For API Gateway, decide the error shape before choosing tools; otherwise the design looks clean but fails when gateway changes.
- Consumer Compatibility: For API Gateway, decide the consumer compatibility before choosing tools; otherwise the design looks clean but fails when api changes.
Production review question
If a team adopts API Gateway, what observable signal proves it helped instead of only making the architecture diagram more fashionable?
Practical metric to track
Track api-gateway health as a named dashboard or review item: combine one user-facing metric, one saturation metric, and one correctness metric. For API Gateway, this keeps the discussion grounded in behavior that can be measured after deployment instead of generic advice that sounds good in an interview but never gets verified.