La Respuesta Corta

Si tienes una sola app detrás de un solo dominio, casi seguro solo necesitas un reverse proxy — algo como NGINX, Caddy o Traefik. Un API gateway es lo que buscas cuando tienes muchos servicios, muchos clientes o reglas estrictas sobre quién puede llamar a qué y con qué frecuencia. Para equipos de menos de cinco personas, el gateway suele ser demasiado, y la sobrecarga que añade (latencia, configuración, una pieza más que se puede romper) suele costar más de lo que ahorra.

Piénsalo como la diferencia entre una recepcionista que saluda y orienta al visitante, y un puesto de seguridad que revisa identificaciones, exige código de vestimenta y registra entradas y salidas. No contratas seguridad para una oficina de una sola habitación.

Qué Hace Realmente un Reverse Proxy

Un reverse proxy se coloca delante de tu backend y hace el trabajo aburrido pero esencial:

  • Termina TLS para que tu app no tenga que gestionar certificados.
  • Rutea peticiones por hostname o ruta hacia el servicio correcto.
  • Cachea respuestas estáticas y a veces de API.
  • Esconde tu backend para que los clientes nunca vean IPs internas.
  • Opcionalmente balancea carga entre un par de copias del mismo servicio.

Lo crucial: hace todo esto sin entender tu API. Ve bytes y rutas. Está bien para una sola app, un monolito o un conjunto pequeño de servicios que controlas de extremo a extremo.

Qué Añade un API Gateway Encima

Un API gateway es un reverse proxy que además entiende tu API. Mientras el reverse proxy es agnóstico a la aplicación, el gateway es consciente de ella. Puede:

  • Aplicar autenticación y autorización (API keys, OAuth, JWT) en un solo sitio en lugar de dentro de cada servicio.
  • Aplicar rate limiting y cuotas por cliente, por ruta, por nivel.
  • Hacer transformación de petición y respuesta — reescribir cabeceras, convertir JSON a XML, mapear campos.
  • Agregar varias llamadas internas en una sola respuesta para el cliente.
  • Traducir protocolos — por ejemplo, recibir HTTP/JSON del cliente y llamar a un backend gRPC.
  • Ofrecer observabilidad rica por API: métricas por ruta, trazas y logs de auditoría.

El trade-off es real. Cada una de esas funciones cuesta algo: un salto de red extra, CPU en el gateway, y una superficie de configuración que tienes que aprender y mantener.

Una Forma Útil de Distinguirlos

Un modelo mental limpio:

  • Reverse proxy → enrutar y optimizar. Cartero eficiente.
  • API gateway → gobernar. Puesto de seguridad más cartero.

Si los verbos que te importan son rutar, cachear, terminar TLS, esconder backends — quieres un reverse proxy. En el momento en que dominan verbos como autenticar, cuotar, transformar, agregar, estás en territorio de gateway.

Cuándo Basta un Reverse Proxy

Para la mayoría de devs independientes y equipos pequeños, el reverse proxy es la herramienta correcta. Encajas bien si:

  • Tienes un servicio o unos pocos que posees por completo.
  • Tu API la usa tu propio frontend o un puñado de clientes de confianza.
  • Haces auth dentro de la app (cookies de sesión, un middleware de token simple).
  • Tu “rate limit” es lo que aguante tu instancia, más un CDN delante.
  • No necesitas métricas separadas por ruta para facturación o compliance.

En este mundo, NGINX o Caddy delante de tu app, con TLS vía Let’s Encrypt, es más que suficiente. Traefik va bien si quieres configuración que siga tus etiquetas de Docker. Tardarás minutos, no días, en montarlo.

Cuándo un API Gateway Empieza a Justificar su Complejidad

Hay momentos concretos en los que el reverse proxy empieza a doler y el gateway se paga solo:

  1. Tienes varios servicios y quieres una capa de auth consistente. Pegar la misma comprobación de JWT en seis servicios es donde nacen los bugs. Un gateway lo centraliza.
  2. Expones APIs públicas o de partners. Desarrolladores externos quieren rutas documentadas, versionado estable y rate limits por clave. Eso es trabajo de gateway.
  3. Necesitas cuotas por cliente o facturación. Si “cuántas llamadas ha hecho el cliente X” es una pregunta que afecta a ingresos, el gateway te lo da gratis.
  4. Traduces protocolos. Clientes REST públicos llamando a servicios gRPC internos es un clásico trabajo de gateway.
  5. Compliance o auditoría está en juego. Cuando alguien pide un log por endpoint de quién accedió a qué, no quieres tener que añadirlo después en cada servicio.

Si nada de eso aplica, el gateway es decoración.

La Sobrecarga Operativa que Nadie Cuenta

Para un equipo de una o dos personas, cada componente nuevo es un impuesto. Un API gateway añade:

  • Latencia. Cada petición paga un salto extra más comprobaciones de auth y políticas. Suele ser pequeño, pero no es cero.
  • Criticidad. Si el gateway es tu única puerta de entrada y se cae, los clientes no ven nada. Necesitas redundancia.
  • Explosión de configuración. Rutas, plugins, políticas, secretos. Ahora eres admin del gateway a tiempo parcial.
  • Versionado y migraciones. Los gateways también versionan, y a veces hay que portar políticas al actualizar.

Para un fundador independiente que lanza un SaaS por la noche, esa sobrecarga es un coste real. La prueba honesta: ¿este componente me va a ahorrar más tiempo al mes del que me cuesta mantenerlo?

Un Camino de Decisión Sencillo

Úsalo cuando tengas dudas:

  1. ¿Un servicio, solo clientes internos? Reverse proxy.
  2. ¿Unos pocos servicios, misma auth, mismo equipo? Reverse proxy con una librería de auth compartida o un sidecar.
  3. ¿Muchos servicios, clientes mezclados, docs públicas, cuotas por clave? API gateway.
  4. ¿APIs públicas vendidas a desarrolladores externos? API gateway, casi seguro.
  5. ¿Tráfico de IA o agentes con cuotas por tokens? Mira gateways conscientes de IA — se apoyan en la misma idea pero miden y gobiernan llamadas a modelos.

También puedes empezar con un reverse proxy y ascender después. No es un fracaso, es el camino sensato. Muchos gateways se pueden desplegar como una capa fina delante de NGINX o Caddy más adelante, sin reescribir tus servicios.

Próximos Pasos Prácticos

  • Si empiezas hoy: Elige Caddy para TLS automático y configuración en un solo archivo, o NGINX si ya lo conoces. Ponlo delante de tu app, termina HTTPS, ruta por hostname, listo.
  • Si estás en el borde de “demasiados servicios”: Dibuja las políticas que realmente necesitas — auth, rate limits, transformaciones. Después busca opciones de gateway (autoalojado o gestionado) que encajen con esa lista, no la que tenga la página de features más larga.
  • Si te preocupa el coste: Ejecuta el reverse proxy en el mismo contenedor o VM que tu app por ahora. Sácalo solo cuando el aislamiento importe.

FAQ

¿Puede un reverse proxy hacer rate limiting? Sí, rate limiting básico por IP. No hace fácilmente límites por API key, por nivel o conscientes de tokens sin trabajo extra.

¿Puede un API gateway reemplazar a NGINX? En muchos despliegues, sí — también gestiona TLS, ruteo y balanceo. La pregunta es si quieres esa superficie extra de configuración para funciones que no usas.

¿Necesito un API gateway para una sola API REST? No. Un reverse proxy basta a menos que expongas esa API a desarrolladores externos con claves y cuotas.

¿Qué pasa con ingress controllers como Traefik? Solapan mucho con los reverse proxies y, con plugins, pueden hacer cosas de gateway. En Kubernetes, un ingress controller suele reemplazar al reverse proxy independiente.

¿Hay una opción “gateway lite”? Sí — algunos gateways tienen modos mínimos, y las service meshes te dan política por servicio sin un gateway completo. Para equipos muy pequeños, una librería de auth compartida más un reverse proxy suele ganar a ambos.

Fuentes