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.
The API Gateway pattern gives them that front door. It places a single entry point in front of many backend services. Clients send every request to the gateway, and the gateway decides which service should handle it.
This chapter covers what the API Gateway pattern is, why microservice architectures use it, what responsibilities it usually takes on, and the trade-offs that come with putting a single entry point in front of many services.
Loading simulation...
1. The Problem with Calling Services Directly
Suppose we are building an e-commerce application using microservices. We have a user service, a product service, an order service, a payment service, and a review service. Each service runs independently and exposes its own API.
Now imagine the mobile app needs to show a product page. It needs product details from the product service, reviews from the review service, and the user's saved addresses from the user service.
Without a gateway, the app calls each of those services directly.
This design creates three problems.
The Client Knows Too Much and Calls Too Often
The client has to know the address of every service it talks to. It also has to make several network calls over a mobile connection, where each round trip can be slow.
| Product Page Dependency | Service | Example Latency on Mobile |
|---|---|---|
| Product details | Product service | 150 ms |
| Reviews | Review service | 180 ms |
| Saved addresses | User service | 130 ms |
If these calls run one after another, the page waits for all of them. If they run in parallel, the page still waits for the slowest one, and the client has to handle retries, timeouts, and the case where one call fails and the others succeed.
Every Service Repeats the Same Work
Every service now has to handle the same concerns on its own, such as checking whether the user is logged in, enforcing rate limits, and logging requests.
| Concern | Problem When Every Service Is Exposed |
|---|---|
| Authentication | Each service validates external tokens separately |
| Rate limiting | Limits are inconsistent across endpoints |
| TLS and certificates | Every service manages its own public certificates |
| CORS | Browser policy is configured in many places |
| Request logging | Logs use different fields, formats, and request IDs |
Duplicated code also means a higher chance that one service gets it wrong. Since the public boundary is also the first security boundary, a single inconsistent service is enough to open a gap.
The Backend Structure Leaks to Clients
Suppose we later split the product service into two smaller services, one for the catalog and one for pricing. Every client that calls the product service directly may need to change.
So the internal structure of the backend leaks out to the clients. Mobile apps make this worse, because old app versions can stay installed for months after a new release.
This is the problem the API Gateway pattern solves.