An API gateway simplifies entry into the system right up to the point where it becomes the heaviest place for routing, security, and access policy decisions.
This chapter breaks the gateway down into explicit responsibilities: routing, authentication, quotas, request transformation, and shielding internal services from external chaos.
For interviews and architecture discussions, it is useful because it tests whether you can separate platform responsibilities from business logic and reason about the cost of centralization.
Central policy point
The gateway is a natural place for authentication, quotas, and access rules, but every mistake here scales instantly across all external traffic.
Critical request path
Every external request crosses the gateway, so its latency, quotas, and transformation rules become part of the user-facing SLA.
Failure modes
Decide in advance what happens when Redis, the auth provider, configuration, or a dependent service fails: what to block, what to simplify, and what to let through.
Operational cost
Monitoring, tracing, staged rollouts, and configuration control at the gateway layer require as much discipline as the microservices behind it.
Related book
Building Microservices
Sam Newman details the role of API Gateway in a microservices architecture.
API Gateway is more than a single entry point for client traffic. It is the layer where routing, security, quotas, traffic transformation, and observability come together. A good gateway simplifies the outer edge of the system; a bad one quickly becomes an overloaded central chokepoint.
Why use an API Gateway?
Functional Requirements
Routing
- Path-based routing (/users → User Service)
- Header-based routing, for example for A/B experiments
- Query parameter routing
- Weighted routing for canary releases
Security
- JWT and OAuth2 token validation
- API key management
- IP allowlists and denylists
- mTLS for service-to-service calls
Rate limits and quotas
- Per-user and per-IP limits
- Per-endpoint throttling
- Burst handling
- Quota management
Traffic transformation
- Request and response transformation
- Protocol translation (REST → gRPC)
- Response aggregation
- Schema validation
Related case
Rate Limiter
Detailed analysis of rate limiting algorithms: Token Bucket, Sliding Window.
Non-functional requirements
< 10ms added
Latency
P99
100K+ RPS
Throughput
per instance
99.99%
Availability
SLA
Horizontal
Scalability
stateless
High-level architecture
Mobile app
Web app
Partner API
IoT devices
Load Balancer
L4/L7
Gateway 1
Gateway 2
Gateway N
User service
Order service
Payment service
External services
Click a client or start the animation to follow the request path
Key patterns
Backend for Frontend (BFF)
A dedicated BFF for each client type, so mobile, web, and admin interfaces can expose different but predictable facades over the same internal services.
Backend for Frontend (BFF)
A dedicated BFF for each client type
CLIENTS
Mobile app
Optimized for constrained devices
Web app
Full user experience
Admin panel
Extended access and control
BFF LAYER
MICROSERVICES
API Composition
The gateway can combine data from several services into one response, so the client does not have to orchestrate a chain of calls on its own.
Advantages:
- Fewer network round trips for the client
- Hides the internal service topology
Risks:
- Higher response latency
- Harder timeout and partial-failure handling
Related book
Release It!
Michael Nygard describes Circuit Breaker and other resilience patterns in detail.
Circuit Breaker in Gateway
Protects the gateway from cascading failures when one dependent service becomes unavailable and starts poisoning the whole entry layer.
Circuit Breaker Simulation
Protection pattern against cascading failures
CLOSED
Normal operation. Requests pass through to the service.
State Transitions
Configuration
0
Total Requests
0
Successful
0
Rejected (Fast)
Fail Fast
Immediate rejection instead of waiting for timeout
Cascading Prevention
Protection from failure propagation
Self-Healing
Automatic recovery after timeout
Documentary
Inside Envoy: The Proxy for the Future
The story of Envoy Proxy and its role next to API gateway and ingress architectures.
Popular solutions
Kong
- Plugin ecosystem
- Lua/Go extensibility
- Declarative configuration
AWS API Gateway
- Lambda integration
- WebSocket support
- Pay-per-request pricing
Envoy
- L7 proxy
- Ready for service mesh
- xDS API
NGINX Plus
- High performance
- Native modules
- Active health checks
Traefik
- Service auto-discovery
- Let's Encrypt integration
- Kubernetes-native operation
Apigee (Google)
- Analytics
- Developer portal
- API monetization
Interview tips
1. Start with the reason the gateway exists
Explain which problem it solves: one entry point, protection of internal services, centralized policies, and unified handling of client traffic. Not just “everyone does this in microservices.”
2. Be explicit about where state lives
The gateway itself is usually kept stateless so it can scale horizontally. Sessions, quotas, and similar shared state belong in Redis or another external store.
3. Treat it like a critical entry point
A gateway easily becomes a single point of failure. Discuss multiple instances, health checks, graceful degradation, and predictable fallback behavior when dependencies fail.
4. Do not turn the gateway into a business service
Keep the gateway focused on platform responsibilities: routing, security, quotas, and traffic transformation. Business logic makes the gateway heavy and harder to evolve.
Key takeaways
- An API Gateway provides a single entry point where routing, security, quotas, and observability come together.
- Gateways are usually kept stateless so they can scale horizontally and be rolled out safely.
- Backend for Frontend (BFF) lets each client type expose its own facade without leaking internal service structure.
- API Composition reduces client round trips, but increases latency and error-handling complexity inside the gateway.
- Circuit Breaker protects the entry layer from cascading failures in dependent services.
- The more business logic you place inside the gateway, the greater the risk of turning a platform layer into a bottleneck.
For additional practice with the API Gateway pattern, review microservices.io: API Gateway pattern and AWS API Gateway Developer Guide.
Related chapters
- System Design Primer (short summary) - provides the baseline design principles for decomposition, API boundaries, and reliability decisions in gateway systems.
- Continuous API Management (short summary) - extends API lifecycle, governance, and contract-driven management around gateway-enabled platforms.
- Customer-friendly API: convenient API for clients - goes deeper into BFF and client-facing facade design on top of internal microservice APIs.
- Rate Limiter - details traffic-shaping algorithms and distributed quota control that are typically enforced at the gateway edge.
- API Security Patterns - complements gateway security responsibilities: authentication, authorization, token policies, and boundary hardening.
- Inter-Service Communication Patterns - explains where gateway responsibilities stop and where downstream synchronous or asynchronous service communication takes over.
- Service Mesh Architecture - clarifies the division of responsibility between the edge gateway and the service mesh inside a microservice platform.
- Inside Envoy: The Proxy for the Future - adds practical context on Envoy as a common L7 foundation for modern API gateway and ingress stacks.
- Resilience Patterns - strengthens timeout, retry, circuit-breaker, and graceful-degradation strategies at the gateway layer.
- Zero Trust - connects gateway design with continuous verification, policy-based access control, and trust minimization.
- Kubernetes Fundamentals - covers the operational side of running gateways in Kubernetes: ingress, autoscaling, service discovery, and staged rollouts.
- Notification System - shows how gateways integrate with multi-channel delivery systems while governing external API traffic.