Какие преимущества у NATS

Что проверяют

Знаете ли вы NATS в его современном виде: чем базовый NATS отличается от JetStream и какие гарантии доставки даёт каждый. Следом почти всегда просят сравнить с Kafka и RabbitMQ и объяснить, что станет с сообщением, если подписчик в этот момент лежит.

Как отвечать

Разделите ответ на два слоя:

• Core NATS: сервер это один бинарник на Go с маленьким потреблением памяти, сообщения ходят по темам (subjects) с масками * и >. Из коробки есть pub/sub, request-reply и queue groups, где сообщение получает один подписчик из группы, то есть готовая балансировка воркеров. Гарантия at-most-once: если подписчика нет, сообщение просто теряется;
• JetStream: слой хранения поверх того же сервера. Стримы с репликацией через Raft, durable-консьюмеры, подтверждения, повторная доставка, дедупликация по заголовку Nats-Msg-Id. На нём же построены Key-Value и Object Store.

Дальше преимущества: низкая задержка, простая эксплуатация (кластер собирается за минуты, без ZooKeeper), топологии из кластеров, суперкластеров и leaf-узлов, мультиарендность через accounts, аутентификация через NKeys и JWT, TLS.

Для Python это клиент nats-py на asyncio: подключение nc = await nats.connect(...), подписка await nc.subscribe(subject, cb=handler), запрос await nc.request(...), JetStream через nc.jetstream().

Честно назовите, где NATS проигрывает: для многолетнего лога событий с перечитыванием и тяжёлой аналитикой привычнее Kafka с партициями, для сложной маршрутизации RabbitMQ.

Где спотыкаются

Обещают гарантированную доставку в базовом NATS. Без JetStream её нет, и это первое, на чём ловят.

Называют NATS Streaming (STAN) актуальным способом хранения. Он устарел и больше не поддерживается, его заменил JetStream.

Делают тяжёлую синхронную работу прямо в обработчике nats-py. Это блокирует цикл событий, сообщения копятся, и сервер отключает клиента как slow consumer. Тяжёлое выносят в отдельные воркеры или в run_in_executor.