API gateway vs balanceador de carga: diferencias

Los dos se ubican delante de tu API, reciben las peticiones antes que el código y las reenvían. Por eso se confunden todo el tiempo. La diferencia está en la pregunta que responde cada uno: el balanceador de carga pregunta "¿qué copia de la aplicación atiende esto?", y el API gateway pregunta "¿esta llamada puede pasar, y a qué servicio va?".

Entender esa separación evita dos errores comunes: poner un gateway pesado en una API que solo necesitaba dos instancias, o esperar de un balanceador de carga reglas de autenticación y cuotas que no aplica.

¿Qué es un balanceador de carga?#

Según la documentación de Elastic Load Balancing de AWS, un balanceador de carga reparte el tráfico entrante entre varios destinos, monitorea su salud y envía peticiones solo a los que están sanos. El objetivo es disponibilidad y capacidad: si una instancia cae, las demás siguen atendiendo.

Trabaja con instancias equivalentes. Todas ejecutan el mismo código y cualquiera puede responder cualquier petición. La decisión es sobre carga, no sobre contenido. Según la capa, ve solo conexiones TCP (capa 4) o también el contenido HTTP (capa 7). Para los algoritmos de reparto, mira algoritmos de balanceo de carga y el artículo qué es un balanceador de carga.

¿Qué es un API gateway?#

Un API gateway es la puerta de entrada de las llamadas a la API. La documentación de Amazon API Gateway lo describe como la capa que se encarga de la gestión del tráfico, la autorización y el control de acceso, el monitoreo y el versionado de APIs. Kong Gateway, otro ejemplo, es un proxy inverso con plugins de autenticación y de límite de tasa por IP, clave de API o consumidor.

Trabaja con servicios distintos. Una ruta /usuarios va a un servicio, /pedidos a otro, y cada ruta puede tener reglas propias: exigir un token, aceptar 100 llamadas por minuto, estar expuesta solo a socios. Concentra en un solo lugar las políticas que se aplican a quien consume la API.

¿Cuáles son las diferencias en la práctica?#

Las funciones se superponen en dos puntos. Muchos balanceadores de carga de capa 7 enrutan por ruta (/api/* a un grupo, /site/* a otro), y casi todo gateway balancea entre las instancias de cada servicio. Por eso, "balanceador de carga" y "API gateway" describen el papel principal de una pieza, no un producto.

¿Cuándo usar un balanceador de carga?#

Úsalo cuando la misma API necesita más de una instancia:

• una instancia no aguanta el pico de peticiones;
• quieres reiniciar una instancia sin tumbar todo el servicio;
• quieres que la falla de un proceso no deje la API fuera de línea.

Un ejemplo mínimo en NGINX, que usa Round Robin por defecto (según la documentación, no hay directiva para activarlo):

upstream api {
    server 10.0.0.11:3000;
    server 10.0.0.12:3000;
}

server {
    listen 80;
    server_name api.ejemplo.com;

    location / {
        proxy_pass http://api;
    }
}

Para cambiar el algoritmo, basta una línea dentro de upstream, como least_conn; o ip_hash;.

¿Cuándo usar un API gateway?#

Úsalo cuando la pregunta deja de ser "cómo reparto la carga" y pasa a ser "cómo controlo quién usa qué":

• tienes varios servicios y quieres una única dirección pública para todos;
• los consumidores externos necesitan clave de API, cuota o plan distinto;
• quieres autenticar, medir y limitar en un solo lugar, en vez de repetir el código en cada servicio;
• necesitas publicar versiones distintas de la API lado a lado.

Para una sola API, el primer paso suele ser el límite de tasa en el propio proxy. Con el módulo limit_req de NGINX:

limit_req_zone $binary_remote_addr zone=perip:10m rate=10r/s;

server {
    listen 80;
    server_name api.ejemplo.com;

    location / {
        limit_req zone=perip burst=20 nodelay;
        proxy_pass http://api;
    }
}

Cada IP recibe 10 peticiones por segundo, con una ráfaga tolerada de hasta 20. Con nodelay, las peticiones de la ráfaga se atienden al instante; sin él, se retrasarían para ajustarse a la tasa. Lo que pase de eso recibe una respuesta de error (503 por defecto, ajustable con limit_req_status). Esto ya es una función de gateway hecha por un proxy común. Cuando necesites cuota por clave de API, planes y panel de uso, es momento de mirar un gateway de verdad.

¿Se pueden usar los dos juntos?#

Sí, y es el diseño más común en sistemas con varios servicios:

1. Un balanceador de carga recibe el tráfico público y lo reparte entre las instancias del gateway, para que el gateway no sea un punto único de falla.
2. El gateway autentica, aplica límites y elige el servicio según la ruta.
3. Cada servicio tiene sus propias instancias, balanceadas detrás del gateway.

En una sola API, es común tener solo el primer punto: un balanceador de carga delante de dos o más instancias, con autenticación y límite de tasa dentro del código. Por debajo, los dos papeles los cumple un proxy inverso. Antes de poner una API en producción, revisa la checklist de API en producción.

Cómo hacerlo en Square Cloud#

En Square Cloud, el balanceo de carga es una función de la plataforma: pones el mismo dominio personalizado en dos o más aplicaciones. El reparto es round-robin con failover pasivo, sin health check activo y sin sticky session. Cada aplicación tiene su propio disco, así que la sesión y el estado van a una base de datos o a Redis. El límite de aplicaciones por dominio depende del plan: 2 en Standard, 5 en Pro y 10 en Enterprise. No hay cobro por petición, y solo funciona con dominio personalizado (desde Standard), no con el subdominio *.squareweb.app.

Todos los planes incluyen WAF, protección DDoS L3/L4/L7 y TLS automático. Las reglas de gateway, como validar la clave de API o aplicar cuotas por cliente, quedan en el código de tu API, con las bibliotecas de tu runtime.

La escala horizontal es manual: no hay autoscaling, así que tú decides cuántas aplicaciones entran en el dominio. Para ver cómo hospedar la API y qué runtimes hay disponibles, mira hosting de APIs.