Комментарии 2
наше приложение хочет получать сообщение ровно 1н раз, не больше и не меньше. При этом мы хотим быть уверенными что если в процессе обработки сообщения консюмер внезапно завершит свою работу(в следствии деплоя, возникновения ошибки или падения сервера, ...) то после перезапуска - это сообщение будет обработано, а не канет в небытие.
AMQP late ack?
То есть Kafka выбрана только потому что уже где-то в компании на другом проекте есть Kafka? В принципе, аргумент серьезный, но не всегда хороший.
А какой у вас объем потока событий? Сколько консюмеров читает и пишет? Сколько партиций предполагается иметь (сейчас и через год)? Сколько серверов будет выделено под кластер Кафки?
Количество сообщений которое мы предполагаем слать в моменте - незначительное(~50-150/min).
Я полностью согласен с тем что, нужно в первую очередь отталкиваться от функциональных/не функциональных требований. В нашем случае брокер сообщений используется в качестве буфера уведомлений о событиях(из реального мира) и мы заранее не можем предугадать сколько будет клиентов и в какой момент он подключится(в силу разных причин).
Исходя из условия что мы не имеем жестких ограничений основанных на функциональных требованиях, плюс имея выгоду, в том плане что каждый клиент может иметь свой consumer.group_id и читать то что ему интересно в удобное ему время, то перед нами стоял лишь вопрос - сможет ли Kafka соответствовать нашим базовым потребностям.
Настройка Kafka для работы в режиме подтверждения о принятии сообщения (ack/nack)