System Design Space
Knowledge graphSettings

Updated: March 2, 2026 at 8:59 AM

API Gateway

mid

Classic task: routing, authentication, rate limiting, load balancing, request/response transformation.

Related book

Building Microservices

Sam Newman details the role of API Gateway in a microservices architecture.

Read review

API Gateway — a single entry point for all client requests in a microservice architecture. This is a critical component that provides routing, security, request transformation, and many cross-cutting concerns.

Why do you need an API Gateway?

Single entry point instead of direct calls to services
Centralized authentication and authorization
Rate limiting and DDoS protection
Request/Response Transformation
API composition and aggregation
Monitoring, logging, tracing

Functional Requirements

Routing

  • Path-based routing (/users → User Service)
  • Header-based routing (A/B testing)
  • Query parameter routing
  • Weighted routing (canary deployments)

Security

  • JWT/OAuth2 validation
  • API key management
  • IP whitelisting/blacklisting
  • mTLS for service-to-service

Rate Limiting

  • Per-user/per-IP limits
  • Per-endpoint throttling
  • Burst handling
  • Quota management

Transformation

  • Request/Response modification
  • Protocol translation (REST → gRPC)
  • Response aggregation
  • Schema validation

Related case

Rate Limiter

Detailed analysis of rate limiting algorithms: Token Bucket, Sliding Window.

Read the case

Non-functional requirements

< 10ms added

Latency

P99

100K+ RPS

Throughput

per instance

99.99%

Availability

SLA

Horizontal

Scalability

stateless

High-level architecture

Click a client to simulate
CLIENTS

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

Redis(Cache & Rate Limits)
Config(etcd / Consul)
Metrics(Prometheus)
Ready

Click a client or start the animation to simulate the request flow

Active Client
Processing Gateway
Target Service

Key patterns

Backend for Frontend (BFF)

A separate API Gateway for each type of client, optimized for its needs.

Backend for Frontend Pattern

A separate BFF for each client type

CLIENTS

Mobile App

Optimized for mobile

Web App

Full-featured

Admin Panel

Extended permissions

BFF LAYER

Mobile App BFF
Web App BFF
Admin Panel BFF

MICROSERVICES

Users
Orders
Payments
Inventory
Analytics
Settings

API Composition

Gateway aggregates data from multiple services into a single response.

Advantages:

  • Reducing the number of round trips
  • Hiding the internal structure

Risks:

  • Increased latency
  • Difficulty handling errors

Related book

Release It!

Michael Nygard is the author of the Circuit Breaker pattern and other stability patterns.

Read review

Circuit Breaker in Gateway

Protection against cascading failures when downstream services are unavailable.

Circuit Breaker Simulation

Protection pattern against cascading failures

CLOSED

Normal operation. Requests pass through to the service.

Failures: 0/3

State Transitions

CLOSED
failures ≥ 3
OPEN
timeout 5s
HALF-OPEN

Configuration

Failure Threshold3
Reset Timeout5s
Base Failure Rate30%

0

Total Requests

0

Successful

0

Rejected (Fast)

Recent Requests
No requests yet

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 history of the creation of Envoy Proxy and its role in the service mesh ecosystem.

Look

Popular solutions

Kong

Open Source / Enterprise
  • Plugins ecosystem
  • Lua/Go extensibility
  • Declarative config

AWS API Gateway

Managed
  • Lambda integration
  • WebSocket support
  • Pay-per-request

Envoy

Open Source
  • L7 proxy
  • Service mesh ready
  • xDS API

NGINX Plus

Commercial
  • High performance
  • Native modules
  • Active health checks

Traefik

Open Source
  • Auto-discovery
  • Let's Encrypt
  • Kubernetes native

Apigee (Google)

Enterprise
  • Analytics
  • Developer portal
  • Monetization

Interview tips

1. Start with "why"

Explain why API Gateway is needed: single entry point, security, cross-cutting concerns. Not just “this is a standard in microservices.”

2. Discuss stateless vs stateful

Gateway must be stateless for horizontal scaling. Status (rate limits, sessions) - in Redis/external store.

3. Consider single point of failure

Gateway is a critical component. Discuss: multiple instances, health checks, graceful degradation, fallback responses.

4. Don't make Gateway too smart

Avoid business logic in Gateway. It should only deal with cross-cutting concerns: auth, routing, rate limiting.

Key Findings

  • API Gateway - single entry point providing routing, security and observability
  • Must be stateless to scale horizontally (state in Redis)
  • Backend for Frontend (BFF) - separate gateway for each type of client
  • The Composition API reduces round trips, but adds latency and complexity
  • Circuit Breaker protects against cascading failures of downstream services
  • Avoid business logic in Gateway - only cross-cutting concerns

For additional practice with the API Gateway pattern, review microservices.io: API Gateway pattern and AWS API Gateway Developer Guide.

Related chapters

Enable tracking in Settings

System Design Space

© 2026 Alexander Polomodov