API Gateway

How to centralize access to your microservices with a single entry point that handles routing, authentication, rate limiting, and response transformation.

What problem it solves

In a microservices architecture, clients (web, mobile, IoT) need to communicate with multiple backend services. Without a centralized entry point, each client must:

• Know the addresses of all the services
• Handle authentication with each service individually
• Deal with different protocols and response formats
• Implement retry logic, timeouts, and circuit breaking on its own

Sin API Gateway:
  Mobile App → Servicio Usuarios (auth + datos)
  Mobile App → Servicio Productos (auth + datos)
  Mobile App → Servicio Pedidos (auth + datos)
  Mobile App → Servicio Pagos (auth + datos)
  
  Cada cliente conoce N servicios
  Cada servicio implementa auth, rate limiting, CORS...

This creates direct coupling between clients and internal services, hinders the independent evolution of services, and duplicates cross-cutting concerns across every microservice.

How it works

The API Gateway acts as a reverse proxy that sits between clients and microservices. All external requests pass through it, and the gateway is responsible for routing them to the correct service.

Con API Gateway:
  Mobile App  ─┐
  Web App     ─┤──► API Gateway ──► Servicio Usuarios
  IoT Device  ─┘         │──► Servicio Productos
                          │──► Servicio Pedidos
                          └──► Servicio Pagos
  
  Un solo punto de entrada
  Cross-cutting concerns centralizados

Core responsibilities

Typical request flow

1. Cliente envía: GET /api/products/123
2. Gateway recibe la solicitud
3. Gateway valida el token JWT → ✅ válido
4. Gateway verifica rate limit → ✅ dentro del límite
5. Gateway enruta a Product Service: GET /products/123
6. Product Service responde con datos del producto
7. Gateway transforma la respuesta (si es necesario)
8. Gateway registra métricas (latencia, status code)
9. Gateway devuelve respuesta al cliente

Composition patterns

The API Gateway can implement different composition strategies:

Simple request routing: Each gateway route maps to a specific service.

/api/users/*     → User Service
/api/products/*  → Product Service
/api/orders/*    → Order Service

Response aggregation: The gateway calls multiple services and combines the responses.

GET /api/dashboard
  → User Service: datos del usuario
  → Order Service: últimos pedidos
  → Product Service: recomendaciones
  ← Respuesta combinada al cliente

Advantages

• Decoupling: Clients don’t know the internal service topology
• Centralized cross-cutting concerns: Auth, rate limiting, and logging are implemented only once
• Independent evolution: You can reorganize internal services without affecting clients
• Client simplification: A single URL, a single authentication format
• Observability: A central point for metrics, logs, and traces of all requests
• Security: Internal services are not exposed directly to the internet

Trade-offs / Disadvantages

• Single point of failure: If the gateway goes down, the entire system becomes inaccessible (requires high availability)
• Additional latency: Every request takes an extra network hop
• Operational complexity: The gateway needs its own deployment, monitoring, and scaling
• Bottleneck: All traffic passes through a single component (requires horizontal scaling)
• Business logic risk: It’s tempting to add business logic to the gateway, which is an anti-pattern
• Coupling to the gateway: Switching gateway technology can be costly

When to use

• Microservices architectures with multiple clients (web, mobile, IoT)
• When you need to centralize authentication and authorization
• When clients need aggregated data from multiple services
• Systems with rate limiting and throttling requirements
• When you want to hide the internal complexity of services from external consumers

When to avoid

• Monolithic applications where there are no multiple backend services
• Internal systems where services communicate directly with each other (service-to-service)
• Prototypes or MVPs where the added complexity isn’t justified
• When the additional latency of an extra hop is unacceptable

Common technologies and implementations

Relationship with other patterns

• BFF (Backend for Frontend): A variant of the API Gateway specialized by client type
• Circuit Breaker: The gateway can implement circuit breaking toward downstream services
• Rate Limiting: A native gateway capability for protecting services
• Service Discovery: The gateway needs to know where the services are (Consul, Eureka, DNS)

Next steps

The API Gateway is the entry point of your architecture. To specialize it by client type, explore the BFF (Backend for Frontend) pattern. To protect downstream services from cascading failures, review the Circuit Breaker.