NATS, SQS или очередь в базе: когда полноценный брокер избыточен?

Не всякая асинхронность требует Kafka. Очередь в базе (таблица задач с SELECT ... FOR UPDATE SKIP LOCKED) закрывает удивительно много: она транзакционна с бизнес-данными, не добавляет инфраструктуры, переживает перезапуски и легко отлаживается; её потолок — тысячи задач в секунду и один экземпляр СУБД. SQS и подобные управляемые очереди снимают эксплуатацию: доставка at-least-once, видимость сообщения на время обработки, встроенная очередь недоставленных, оплата по факту; порядок гарантируется только в FIFO-режиме с ограничением пропускной способности. NATS — минималистичный брокер с очень низкой задержкой; в варианте JetStream добавляются персистентность, повторное чтение и подтверждения. Kafka оправдана там, где нужны перечитывание истории, несколько независимых потребителей одного потока, высокая пропускная способность и стриминговая обработка. Выбор делают по требованиям к сохранности, порядку, скорости и по готовности эксплуатировать кластер.