Что мы на нём делаем
NATS — способ сервисам разговаривать, не зная друг о друге. Сервис публикует, что что-то произошло; те, кому это важно, подписываются. В коде публикующего ничего не меняется, когда появляется новый потребитель, — и именно это свойство не даёт системе превратиться в паутину прямых HTTP-вызовов всех ко всем.
Он умеет и request/reply, поэтому может заменить межсервисный HTTP там, где маршрутизацию и повторы хочется получить готовыми, а не переписывать в каждом клиенте заново.
Где он нужен
Между бэкенд-сервисами, рядом с Go, — real-time рассылка, уведомления о событиях и развязка того, кто фиксирует событие, и тех, кто на него реагирует.
Берём мы именно NATS из-за эксплуатационного веса. Это один небольшой бинарник с простой конфигурацией — совсем другое обязательство, чем поднимать и настраивать полноценный кластер брокера для системы, которой это пока не нужно.
Когда мы его рекомендуем
Когда сервисов больше пары и они начинают вызывать друг друга напрямую, или когда события нужно доставлять набору потребителей, который будет расти.
Не для продукта из одного сервиса — внутрипроцессная очередь или Redis проще в эксплуатации и справятся. А если нужно долговременное хранение событий с воспроизведением на больших окнах хранения, лучше подойдёт лог-ориентированная система; NATS с JetStream закрывает многое из этого, но выбирать его стоит осознанно, а не по умолчанию.