API Gateway Request Flow: Mermaid Flowchart

API Gateway Request Flow flowchart diagram

About Source

An API gateway is a single entry point that sits in front of all your backend services, handling cross-cutting concerns — authentication, rate limiting, routing, request transformation, and observability — before passing the request to the appropriate upstream service.

What the diagram shows

This flowchart maps the decision tree that every inbound request traverses inside an API gateway:

1. Receive request: the gateway accepts the inbound HTTP request from the client. 2. Authenticate: the gateway validates credentials (API key, JWT, OAuth token). Invalid credentials result in an immediate 401 response. 3. Authorize: after identity is confirmed, the gateway checks whether the caller has permission for the requested resource (403 if not). 4. Rate limit: the gateway enforces per-client or per-route quotas. Exceeded quotas return 429 Too Many Requests. 5. Route: the gateway pattern-matches the request path against its routing table to identify the target upstream service. 6. Transform request: headers may be rewritten, payloads translated, or query parameters normalized before forwarding. 7. Proxy to service: the gateway forwards the request to the upstream microservice. 8. Transform response: the upstream response may be reshaped (e.g., envelope stripped) before returning to the client.

Why this matters

Without a gateway, each microservice must independently implement auth, rate limiting, and observability. This creates inconsistency and maintenance overhead. Centralizing these concerns in the gateway keeps services thin and focused on business logic.

For the downstream perspective, see Microservice Request Chain to understand what happens after the gateway forwards the request. Service Discovery Flow explains how the gateway resolves the upstream address dynamically. For traffic control specifics, explore Rate Limiting Architecture.

Frequently asked questions

An API gateway is a single entry point that sits in front of all your backend services and handles cross-cutting concerns — authentication, rate limiting, routing, and request transformation — before passing the request to the appropriate upstream service. It keeps individual services thin by centralizing shared infrastructure logic in one place.

The gateway receives the inbound HTTP request and runs it through a sequential decision tree: it first authenticates credentials (returning 401 on failure), then authorizes permissions (returning 403 on failure), then enforces rate limits (returning 429 on excess), then pattern-matches the path against a routing table, and finally transforms and proxies the request to the target upstream service before transforming the response back.

Use an API gateway when you have multiple backend services that all need consistent auth, rate limiting, and observability. It becomes essential in microservices architectures where duplicating these concerns in every service would create maintenance overhead and inconsistency. Single-service applications may not justify the added infrastructure complexity.

A frequent mistake is applying overly broad routing rules that send unintended traffic to the wrong upstream service. Another is caching auth decisions too aggressively, which can allow stale tokens to pass. Teams also frequently forget to configure upstream timeouts in the gateway — without them, a slow service can hold open connections until the gateway's default (often very long) timeout triggers.

mermaid

flowchart TD
    A([Client Request]) --> B[API Gateway receives request]
    B --> C{Authenticate}
    C -- Invalid credentials --> D[Return 401 Unauthorized]
    C -- Valid --> E{Authorize}
    E -- Forbidden --> F[Return 403 Forbidden]
    E -- Allowed --> G{Rate limit check}
    G -- Quota exceeded --> H[Return 429 Too Many Requests]
    G -- Within quota --> I[Match route to upstream service]
    I --> J{Route found?}
    J -- No match --> K[Return 404 Not Found]
    J -- Matched --> L[Transform request headers and payload]
    L --> M[Proxy to upstream service]
    M --> N{Upstream response}
    N -- 5xx error --> O[Return 502 Bad Gateway]
    N -- Success --> P[Transform response]
    P --> Q([Return response to client])