¿Qué hace realmente un API gateway y por qué poner uno delante de tus microservicios?

#El problema sin un gateway

Imaginemos una app móvil que necesita mostrar el panel de un usuario: su perfil, sus pedidos recientes y la disponibilidad actual de inventario para los artículos en su carrito. Sin un gateway, el cliente llama directamente a tres microservicios separados — users-service, orders-service, inventory-service — cada uno en su propio host, cada uno exigiendo su propia verificación de autenticación, cada uno con su propio límite de tasa, si es que lo tiene. Cada cliente (la app móvil, la app web, el servidor de un partner) tiene que conocer las tres direcciones, implementar la misma lógica de autenticación tres veces, y hacer tres idas y vueltas justo donde la red es más lenta — a menudo sobre una conexión móvil.

Ahora multipliquemos eso por cada servicio que se agregue en los próximos dos años. Las preocupaciones transversales — autenticación, throttling, logging, terminación TLS — terminan duplicadas dentro de cada servicio, o peor, implementadas de forma inconsistente entre ellos. Un API gateway existe para sacar todo eso de los servicios individuales y concentrarlo en un solo lugar, en el borde, delante de todo.

#Qué hace realmente un gateway

Un API gateway es un proxy inverso construido específicamente para ese rol de borde. Cuatro responsabilidades aparecen en prácticamente todo despliegue real:

• Ruteo (routing) — examina la ruta, el host o el encabezado de la petición entrante y la reenvía al servicio correcto, a menudo manejando también el versionado de la API (/v1/orders frente a /v2/orders) y divisiones de tráfico blue/green o canary.
• Autenticación y autorización — valida las credenciales de quien llama (una API key, un JWT?, una cookie de sesión) una sola vez, en el borde, y rechaza la petición de plano o la reenvía con una identidad interna en la que los servicios confían (un encabezado ya validado, un token interno de vida corta). Los servicios individuales ya no reimplementan cada uno la validación de tokens.
• Rate limiting y cuotas — limita a quienes llaman por API key, por IP o por plan de suscripción, protegiendo a los servicios de atrás de ser saturados por un cliente ruidoso y permitiendo planes de precios escalonados sin tocar la lógica de negocio.
• Agregación (composición) — para endpoints que necesitan datos de varios servicios, el gateway (o una capa Backend-for-Frontend construida sobre él) puede abrir en abanico una sola petición entrante hacia varias llamadas internas y fusionar los resultados en una sola respuesta, de modo que el cliente móvil del ejemplo obtenga su panel en una sola ida y vuelta en lugar de tres.

Más allá de esas cuatro, los gateways suelen manejar también terminación TLS, caché de respuestas, transformación de peticiones y respuestas (adaptar la forma que espera un cliente antiguo al contrato de un backend nuevo), y observabilidad centralizada — cada petición pasa por un único punto de estrangulamiento, así que ese es el lugar natural para emitir logs, métricas y trazas distribuidas consistentes.

#Dónde deja de valer la pena

Una distinción que aparece seguido en entrevistas es API gateway contra service mesh — resuelven problemas relacionados pero distintos, en capas diferentes del patrón de tráfico: