<aside>
Contenido
</aside>
<aside>
El flujo es: cuando se crea o actualiza un cliente en ms-clientes, se publica un evento a RabbitMQ. ms-cuentas lo escucha y actualiza el nombre localmente.
Cuando se crea un cliente, ms-clientes manda un mensaje JSON al Exchange. No le importa quién lo recibe ni si alguien lo lee. Solo lo suelta.
El Exchange recibe el mensaje y decide a qué Queue mandarlo usando el Routing Key (cliente.evento).
La Queue guarda el mensaje hasta que alguien lo consuma. Si ms-cuentas está caído, el mensaje no se pierde, se queda esperando en la Queue. Cuando ms-cuentas vuelve a levantar, lo procesa. Esto es lo que hace RabbitMQ asíncrono, el productor no espera respuesta.
ms-cuentas (con @RabbitListener) toma el mensaje de la Queue, actualiza el clienteNombre en las cuentas, y le dice a RabbitMQ que ya lo procesó (ACK). RabbitMQ entonces elimina el mensaje de Queue.
RabbitMQ tiene varios tipos de Exchange. Usamos Topic porque permite routing flexible con patrones. Si mañana agregamos más eventos (cliente.creado, cliente.eliminado, cuenta.creada) puedemos filtrar con wildcards: cliente.* escucha todos los eventos de cliente. Con Direct solo podrías hacer matching exacto.
Para nuestro caso actual con 2 microservicios y un solo consumer, Topic funciona pero es más por preparación a futuro. Entonces elegimos Topic Exchange porque permite escalar el routing sin modificar el productor. Si después agregamos un servicio de notificciones que solo necesita escuchar eliminaciones , se suscribe con cliente.eliminado sin tocar ms-clientes.
La queue es durable, los mensajes persisten en disco. Si el consumidor está caído, los mensajes se acumulan y se procesan cuando vuelve. No se pierde información.
</aside>