diagrams
System Design

API Gateway Architecture

An API gateway is a single entry-point server that sits between external clients and backend services, handling cross-cutting concerns like authentication, rate limiting, routing, and protocol translation.

diagram.mmd — flowchart
Edit in Graphlet →
API Gateway Architecture flowchart diagram
About Source

An API gateway is a single entry-point server that sits between external clients and backend services, handling cross-cutting concerns like authentication, rate limiting, routing, and protocol translation.

What the diagram shows

The diagram shows three client types — a Web App, Mobile App, and Third-Party Client — all sending requests to a central API Gateway. Within the gateway, the request passes through a pipeline of middleware: first Auth & JWT Validation rejects unauthenticated requests early; then Rate Limiter enforces per-client quotas; and finally Request Router inspects the path and method to select the correct upstream service.

Downstream, the gateway fans out to four backend services: User Service, Product Service, Order Service, and Analytics Service. The gateway also integrates with a Cache Layer to serve repeated read requests without hitting upstream services, and forwards logs to a Logging & Monitoring system.

Why this matters

Without a gateway, every client would need to know the address of every service and implement auth and rate-limiting logic independently. The gateway pattern centralizes that complexity, presenting clients with a single stable hostname while the backend topology evolves freely behind it. It also enables A/B routing, canary traffic splitting, and request transformation without touching application code.

For a step-by-step trace of a single request through the gateway, see API Gateway Request Flow. For the full microservice topology the gateway sits in front of, see Microservice Architecture. Rate limiting specifics are in Rate Limiting Architecture.

Free online editor
Edit this diagram in Graphlet
Fork, modify, and export to SVG or PNG. No sign-up required.
Open in Graphlet →

Frequently asked questions

An API gateway is a reverse-proxy server that acts as the single entry point for all client traffic, centralizing cross-cutting concerns — authentication, rate limiting, routing, and logging — so individual backend services do not need to implement them independently.
A request arrives at the gateway, passes through a middleware pipeline (auth validation, rate limiting, request transformation), and is then routed to the appropriate upstream service. The response is returned to the client, optionally after caching or response transformation.
Use an API gateway when you have multiple backend services that share common concerns like authentication or rate limiting, when you need a stable public hostname that abstracts backend topology changes, or when you want to enable traffic splitting and A/B routing at the infrastructure level.
The most common mistakes are pushing too much business logic into the gateway (it should handle infrastructure concerns only), setting overly permissive rate limits, and neglecting to configure circuit breakers on upstream calls — which can cause the gateway itself to become a bottleneck under backend failures.
mermaid
flowchart LR WebApp([Web App]) --> GW MobileApp([Mobile App]) --> GW ThirdParty([Third-Party Client]) --> GW subgraph GW[API Gateway] Auth[Auth & JWT\nValidation] RL[Rate Limiter] Router[Request Router] Auth --> RL --> Router end Router --> UserSvc[User Service] Router --> ProductSvc[Product Service] Router --> OrderSvc[Order Service] Router --> AnalyticsSvc[Analytics Service] Router --> CacheLayer[(Cache Layer\nRedis)] GW --> Logging[Logging &\nMonitoring]
Copied to clipboard