API Gateway Pattern
Last Updated: May 26, 2026
Service discovery helps services find each other inside the system. External clients still need a stable and controlled way to enter it.
A mobile app, browser, or partner integration should not need to know the internal service map. Directly exposing every backend service creates chattiness, duplicated edge policy, and tight coupling to backend boundaries.
The API Gateway pattern places a controlled entry point in front of backend services. Clients call the gateway, and the gateway handles edge concerns such as routing, authentication, rate limits, request shaping, protocol translation, observability, and selected aggregation.
The goal is to keep the public API stable while backend services evolve behind it.
The Problem: Exposing Services Directly
Consider a commerce mobile app. The home screen needs product recommendations, cart state, recent orders, promotional banners, and user profile data.
Without a gateway, the app calls each backend service directly.
This design creates four problems.
1. Client Chattiness
Every network round trip adds latency and failure probability. Parallel requests help, but connection setup, TLS negotiation, cellular network variance, retries, and request coordination still happen in the client.
| Home Screen Dependency | Example Latency |
|---|---|
| Product recommendations | 150 ms |
| Cart summary | 120 ms |
| Recent orders | 180 ms |
| Promotional banners | 100 ms |
| User profile | 130 ms |
If these calls run sequentially, the screen waits on the sum. If they run in parallel, the screen still waits on the slowest dependency, plus client-side orchestration overhead. On a mobile network, each extra request is another timeout, retry, or partial-render case.
2. Tight Coupling to Backend Boundaries
Direct clients become coupled to internal service ownership.
If the order domain splits into order, shipping, and fulfillment services, every direct client must learn the new topology. Mobile clients make this worse because old app versions may stay active for months.
3. Duplicated Edge Concerns
External-facing concerns tend to be repeated poorly when every service exposes its own public API.
| Concern | Direct Exposure Problem |
|---|---|
| Authentication | Each service validates external tokens separately |
| Authorization | Policy decisions drift between services |
| Rate limiting | Limits are inconsistent across endpoints |
| TLS and certificates | Every service manages public edge security |
| CORS | Browser policy is configured in many places |
| Request logging | Logs use different fields, formats, and correlation IDs |
The edge is also the first security boundary. Inconsistent behavior at that boundary becomes an operational risk.
4. Protocol and Payload Mismatch
External clients usually want stable HTTPS APIs. Internal services may use gRPC, event streams, queues, private HTTP endpoints, or provider-specific APIs.
Browsers usually consume HTTPS APIs. Mobile clients need stable screen-oriented endpoints, independent of the current backend decomposition. Partner APIs should receive public contract fields, not internal fields such as password_hash, fraud flags, or service-specific debug metadata.