Proxy reverso

Los dos están adelante y reciben todo. La diferencia es qué miran para decidir a dónde va cada pedido.

Elige entre iguales, por carga. Las tres apps son copias: da lo mismo cuál atiende.

Elige entre distintos, por ruta. Mira la URL y la manda al servicio que sabe responderla.

El proxy tiene una tabla de reglas. La primera que coincide con la ruta decide el servicio. Cambiala en vivo.

• Sin regla para una ruta: 404 desde el proxy.
• Regla hacia el servicio equivocado: el pedido llega, pero el servicio no conoce la ruta y el 404 lo da él.
• También se puede enrutar por host (api. vs. www.) o por header (X-Version: 2).

Atrás puede haber uno, cuatro o veinte servicios. El cliente no lo sabe: solo conoce al proxy.

• Partir un servicio en dos es agregar una regla: el cliente no cambió nada, y adelante no hubo que escribir código ni deployar.
• Los servicios no quedan expuestos a internet: solo el proxy.

Como todo pasa por el proxy, hay tareas que conviene hacer ahí y no repetirlas en cada servicio.

El proxy elige el servicio por la ruta. Adentro de cada servicio hay varias copias, y entre ellas se balancea como en la clase anterior.

• Muchos proxies hacen las dos cosas: enrutan y balancean.
• Cada servicio escala por separado, según su propia carga.

Todo el tráfico pasa por el proxy: es un punto único de falla.

• Se mitiga con un esquema activo/pasivo: la pasiva queda en espera y toma el tráfico si la activa se cae (failover).
• Suma un salto más de latencia a cada pedido.
• Tentación peligrosa: meter lógica de negocio en el proxy.

Todo API gateway es un proxy reverso; no todo proxy reverso es un API gateway. Suma lo que importa con clientes de una API.

App móvil: se porta bien, 1 pedido/s y casi siempre con token.

• Agregación: un pedido del cliente → varios servicios → una sola respuesta (espera al más lento).
• BFF (backend for frontend): un gateway por tipo de cliente, web y móvil.