Выбор RabbitMQ обычно объясняют моделью очереди задач, маршрутизацией и подтверждениями, а Kafka — потребностью в журнале событий, повторном чтении и независимых потребителях. Универсального победителя нет.
Выбор Redis для очереди можно обосновать простотой, имеющейся инфраструктурой и приемлемыми гарантиями. Но сравнивать нужно конкретный механизм очереди, а не только названия Redis, Kafka и RabbitMQ.
Самописный брокер может быть оправдан узкой семантикой или историческими ограничениями, но требует самостоятельно обеспечивать надёжность и эксплуатацию. Конкретную причину выбора нужно подтвердить контекстом.
Выбор должен следовать требованиям: журнал с retention, replay, partitions и независимыми группами часто ведёт к Kafka; сложная маршрутизация и task queues могут вести к RabbitMQ.
Разделите опыт с Kafka и RabbitMQ и назовите реальные сценарии: поток событий, очереди заданий, маршрутизация или интеграции. Знакомство с одним не означает опыт со вторым.
Для retry нужны устойчивое хранение, задержка, подтверждение новой публикации и идемпотентная обработка. Обычная связка TTL и DLX сама по себе не гарантирует отсутствие потерь.
Три брокера могут решать разные задачи: журнал событий, очереди работ и обмен сообщениями. Такое разделение должно оправдывать сложность сопровождения.
Сравните скорость публикации и подтверждённой обработки, затем разделите ready и unacked. Рост ready указывает на недостаточную обработку, unacked — на задержку уже выданных сообщений.