API Gateway Pattern
Practice this topic in a realistic system design interview
Service discovery helps services find each other inside the system. Clients outside the system still need one stable front door.
A mobile app, browser, or partner integration should not need to know which internal service owns products, carts, orders, or users. If every backend service is exposed directly, clients make too many calls, security rules get copied everywhere, and even small backend changes can force client changes.
The API Gateway pattern puts a controlled entry point in front of backend services. Clients call the gateway. The gateway routes the request, checks who is calling, applies limits, shapes requests and responses, translates protocols when needed, records useful logs and metrics, and sometimes combines results from several services.
The goal is simple: keep the public API stable while backend services change behind it.
This chapter covers what the API gateway pattern does, its responsibilities, and where it helps.
Loading simulation...
1. 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 common problems.
Too Many Client Calls
Every network call adds latency and another chance for failure. Parallel requests help, but the client still has to handle connection setup, TLS, slow mobile networks, retries, timeouts, and partial results.
| 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 one after another, the screen waits for all of them. If they run in parallel, the screen still waits for the slowest one, plus the extra client-side work needed to coordinate the results. On a mobile network, each extra request is another possible timeout, retry, or half-loaded screen.
Tight Coupling to Backend Boundaries
Direct clients become tied to the current shape of the backend.
If the order area splits into order, shipping, and fulfillment services, every direct client must learn the new layout. Mobile clients make this harder because old app versions may stay active for months.
Duplicated Edge Concerns
Public API concerns tend to be copied poorly when every service exposes its own endpoint.
| 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 public boundary is also the first security boundary. If behavior is inconsistent there, the system becomes harder to secure and operate.
Protocol and Payload Mismatch
External clients usually want stable HTTPS APIs. Internal services may use gRPC, event streams, queues, private HTTP endpoints, or APIs from third-party providers.
Browsers usually consume HTTPS APIs. Mobile clients need endpoints shaped around screens, not around whichever services happen to exist today. Partner APIs should receive only public contract fields, not internal fields such as password_hash, fraud flags, or service-specific debug data.