Proxy, balanceador y API gateway: responsabilidades distintas
Una solicitud puede atravesar varios intermediarios antes de llegar al código de negocio. Aunque un producto combine funciones, distinguir sus responsabilidades ayuda a decidir dónde aplicar cada política.
Proxy directo e inverso
Un forward proxy actúa por cuenta del cliente. Puede controlar el acceso saliente o centralizar registros. El destino recibe la conexión del proxy, pero eso no garantiza anonimato: cabeceras, autenticación y contenido pueden identificar al usuario.
Un reverse proxy representa a uno o varios servidores. El cliente se conecta a una dirección pública y el intermediario reenvía al backend. Puede terminar TLS, enrutar por host y ocultar la topología interna. Proxificar describe la intermediación y no exige tener varias instancias equivalentes.
Balanceador: elegir una instancia
Si una aplicación tiene diez réplicas que atienden la misma función, un balanceador selecciona cuál recibe una conexión o solicitud. Puede utilizar round robin, conexiones activas o pesos y excluir destinos que fallan comprobaciones de salud.
No crea capacidad por sí solo: hace utilizable un conjunto de servidores. Tampoco garantiza que una operación interrumpida se haya revertido. Si se reintenta una petición que crea una orden, el servicio necesita reconocer duplicados.
Gateway: una entrada con políticas
Una puerta de enlace de API puede autenticar clientes, aplicar cuotas, validar solicitudes, recoger métricas y dirigir recursos a servicios especializados. /usuarios puede llegar al servicio de identidad; /pedidos, al de órdenes. Una API key puede identificar un consumidor o plan, pero no sustituye necesariamente la identidad y permisos del usuario.
Amazon API Gateway documenta este papel como una capa de publicación y acceso a backends. Las capacidades concretas varían por producto y tipo de API; no todos ofrecen las mismas transformaciones o políticas.
Cómo se combinan
En una arquitectura posible, el gateway valida y selecciona el servicio, y un balanceador distribuye el tráfico entre sus réplicas. En otra, una implementación reúne ambas funciones. Los términos no obligan a desplegar tres equipos separados.
La autorización del recurso debe seguir siendo correcta dentro del servicio: aceptar un token no demuestra que su portador pueda editar cualquier pedido. También conviene definir timeouts, propagación de identidad e identificadores de correlación para reconstruir el recorrido de cada petición.