API Gateway in System Design

What is API Gateway?
An API Gateway is a server that sits between the client (web app, mobile app, frontend) and your backend services (microservices).

Instead of the client directly calling multiple services, it sends all requests to the API Gateway, and the gateway routes the request to the appropriate service.

Without API Gateway

Client
  |
  |-----> User Service
  |
  |-----> Product Service
  |
  |-----> Order Service
  |
  |-----> Payment Service

The client needs to know:

1. URLs of all services
2. Authentication mechanism of all services
3. Error handling of all services

This becomes difficult to manage.

With API Gateway

Client
   |
   |
API Gateway
   |
   |------> User Service
   |
   |------> Product Service
   |
   |------> Order Service
   |
   |------> Payment Service

Now the client only knows one URL: https://api.mycompany.com
Everything else is handled by the gateway.

Real-world Example Suppose you're building an e-commerce application.

Frontend needs:

Login
Product details
Place order
Make payment

Without Gateway

https://user.mycompany.com/login
https://product.mycompany.com/products
https://order.mycompany.com/orders
https://payment.mycompany.com/pay

With Gateway

https://api.mycompany.com/login
https://api.mycompany.com/products
https://api.mycompany.com/orders
https://api.mycompany.com/pay

The gateway routes internally.

Responsibilities of API Gateway

1. Request Routing

/api/users/*      -> User Service
/api/orders/*     -> Order Service
/api/products/*   -> Product Service

2. Authentication: Instead of every service validating JWT, only API Gateway does that.

Client
   |
 JWT Token
   |
API Gateway
   |
Valid Token?
   |
Yes -> Forward
No  -> Return 401

3. Authorization
4. Rate Limiting
5. Load Balancing
6. Caching
7. Logging
8. SSL Termination
9. Response Aggregation

Comments

[arun rajkumar]

Clean breakdown. One nuance from running this in production: centralizing auth at the gateway is the right default, but watch that it doesn't become a god-object every team has to touch to ship anything. We keep coarse checks at the gateway (valid token, rate limits, routing) and push fine-grained authz — "can THIS user touch THIS resource" — down into the service that owns the data, because only it has the context to decide. The gateway answers "should this request exist at all"; the service answers "is this request allowed." We run Traefik v3 for exactly the routing/SSL-termination layer you describe. One thing I'd add to the list: how are you handling the gateway's own failure mode — is it redundant, or does it quietly become a single point of failure for everything behind it?

[Rohit Sharma]

Great point. In practice, the gateway shouldn't become a giant "god service" that every authorization rule gets added to. I usually think of it as:

• Gateway: "Should this request exist at all?" (token validation, rate limiting, routing, basic security checks)
• Service: "Is this request allowed?" (resource ownership, roles, business-specific permissions)

The service that owns the data has the necessary context to make fine-grained authorization decisions, so pushing all authz into the gateway often creates tight coupling and slows teams down.

Regarding failure modes, you're absolutely right that the API Gateway can become a single point of failure if deployed as a single instance. In production it's typically made highly available by:

• Running multiple gateway instances behind a load balancer
• Deploying across multiple availability zones/regions
• Using health checks and automatic failover
• Keeping gateway instances stateless so they can be replaced quickly
• Optionally having multiple gateway replicas with rolling deployments

The gateway is logically a single entry point, but it should never be a single server.