Почему используется NATS вместо RabbitMQ или Kafka
Что проверяют
Умеете ли вы выбирать брокер по требованиям, а не по популярности. Три системы решают разные задачи, и интервьюер ждёт, что вы назовёте требование, при котором выбор меняется, а не будете хвалить одну из них.
Как отвечать
Разложите по сути. Базовый NATS это лёгкая шина publish/subscribe без хранения: доставка не более одного раза, тем нет как сущности, есть subject с шаблонами, request/reply встроен в протокол, брокер разворачивается одним небольшим процессом без внешних зависимостей. Отсюда и профиль применения: быстрый обмен между сервисами, служебные команды, опрос состояния, случаи, где потеря отдельного сообщения не критична.
Нужна надёжность, включается JetStream: стрим хранит сообщения, потребитель подтверждает обработку, появляется доставка не менее одного раза, повторы, политики хранения, а поверх этого KV и объектное хранилище.
RabbitMQ силён другим: гибкая маршрутизация через обменники и ключи, очередь недоставленных сообщений, приоритеты, отложенные сообщения. Это классические рабочие очереди. Kafka это упорядоченный лог с партициями и длительным хранением, где чтение не удаляет сообщение, поэтому она выигрывает там, где нужен повтор истории и потоковая обработка.
Вывод формулируйте условием: NATS берут за низкую задержку и простую эксплуатацию, Kafka за повтор и порядок, RabbitMQ за маршрутизацию и очереди задач.
Где спотыкаются
Оперируют цифрами пропускной способности без режима. Впечатляющие числа меряются на обмене без сохранения на диск, и сравнивать их с записью в лог с подтверждением некорректно.
Забывают, что базовый режим теряет сообщения. Если подписчика нет в момент публикации, сообщение просто не доедет, а медленного потребителя брокер отключит. Требуется гарантия, значит нужен JetStream с подтверждениями, и разговор про простоту сразу становится честнее.
Переносят ожидания одной системы на другую: ждут от шины повтора истории, как в логе, или пытаются сделать из лога очередь задач с точечным подтверждением каждой единицы работы. И отдельно про эксплуатацию: простота установки ничего не говорит про кластер с хранением, мониторинг, отставание потребителей и план восстановления нужны в любом случае.