Qué construimos con él
NATS es cómo hablan los servicios entre sí sin saber unos de otros. Un servicio publica que ha pasado algo; los servicios a los que les importe se suscriben. Nada en el código del publicador tiene que cambiar cuando aparece un consumidor nuevo, y esa es la propiedad que impide que un sistema se convierta en una maraña de llamadas HTTP directas entre todo.
También hace petición/respuesta, así que puede sustituir al HTTP entre servicios donde prefieras que el enrutado y los reintentos vengan resueltos en vez de reimplementados en cada cliente.
Dónde encaja
Entre servicios de backend, junto a Go: fan-out en tiempo real, notificación de eventos y desacoplar aquello que registra un evento de aquello que reacciona a él.
La razón por la que recurrimos a NATS en concreto es el peso operativo. Es un único binario pequeño con una configuración simple, y eso es un compromiso muy distinto de administrar y ajustar un clúster de broker completo para un sistema que todavía no lo necesita.
Cuándo lo recomendamos
Cuando tienes más de un par de servicios y empiezan a llamarse directamente entre ellos, o cuando necesitas entregar eventos a un conjunto de consumidores que va a crecer.
No para un producto de un solo servicio: una cola en proceso o Redis es menos que administrar y hace el trabajo. Y si necesitas almacenamiento duradero de eventos a largo plazo con reproducción sobre ventanas de retención grandes, un sistema orientado a log encaja mejor; NATS con JetStream cubre buena parte de ese terreno, pero elígelo de forma deliberada y no por defecto.