API Gateway

When we move from a monolith to microservices, our clients suddenly need to know about 10 different services with 10 different URLs. That’s a mess. An API Gateway solves this by giving clients one single door to walk through. Behind that door, it routes requests to the right service.

What Is an API Gateway?

An API Gateway is a server that sits between clients and our backend services. Every request goes through it first. It’s the receptionist of our microservices architecture — it knows where everything is and handles common tasks so individual services don’t have to.

What Does It Do?

An API Gateway handles a bunch of cross-cutting concerns:

• Request Routing — Routes /api/users to the User Service, /api/orders to the Order Service
• Authentication & Authorization — Validates JWT tokens, API keys, or OAuth before the request even reaches a service
• Rate Limiting — Stops a single client from hammering our services (e.g., 100 requests/minute)
• Load Balancing — Distributes requests across multiple instances of a service
• Request/Response Transformation — Converts between protocols (REST to gRPC, XML to JSON)
• Response Aggregation — Combines responses from multiple services into one response for the client
• Caching — Caches frequent responses to reduce load on services
• Logging & Monitoring — Centralized request logging, metrics, and tracing

Where It Sits in the Architecture

Without a gateway, every client would need to know every service URL, handle auth separately, and manage its own retry logic. That’s a nightmare, especially for mobile apps.

API Gateway vs Load Balancer

This comes up a lot in interviews. They’re related but different:

In simple language, a load balancer says “here are 5 copies of the same thing, pick one.” An API gateway says “what are we looking for? Let me take us to the right place.”

In practice, we often use both. The API gateway routes to the right service, and a load balancer in front of each service distributes traffic across its instances.

Response Aggregation — The Big Win

One of the most valuable things an API gateway does is aggregation. Say a mobile app’s home screen needs data from 3 services:

Without a gateway: the app makes 3 separate HTTP calls (slow on mobile, battery drain).

With a gateway: the app makes 1 call, the gateway fans out to 3 services internally, combines the results, and returns a single response. Way faster for the client.

Client → GET /api/home

Gateway internally:
  → GET /users/123      → User Service
  → GET /orders/recent  → Order Service
  → GET /recommendations → Rec Service

Gateway combines all three and returns one response.

Popular API Gateway Tools

• Kong — Open-source, plugin-based, built on Nginx. Very popular.
• AWS API Gateway — Fully managed, integrates with Lambda and other AWS services. Pay per request.
• Nginx — Can act as a basic API gateway with reverse proxy config. Lightweight and fast.
• Traefik — Cloud-native, auto-discovers services in Docker/Kubernetes.
• Express Gateway — Node.js-based, good for teams already in the JS ecosystem.

For Kubernetes, an Ingress Controller (like Nginx Ingress or Traefik) often serves as the API gateway.

Potential Downsides

The API gateway is powerful, but it’s not free:

• Single point of failure — If the gateway goes down, everything goes down. We need it highly available (multiple instances + health checks).
• Added latency — Every request goes through an extra hop. Usually negligible, but it adds up.
• Can become a bottleneck — All traffic funnels through it. We need to scale the gateway itself.
• Complexity — More infrastructure to maintain, configure, and monitor.

Key Takeaway

An API Gateway is the front door to our microservices. It handles the boring-but-critical stuff (auth, routing, rate limiting, logging) so our services can focus on business logic. In a monolith we don’t need one. In a microservices architecture, we almost always do.