⚔️ Kafka или RabbitMQ: как выбрать брокер под задачу


📌 «Kafka — для больших высоконагруженных систем, RabbitMQ — для маленьких» — плохой критерий выбора.


Брокер выбирают по модели взаимодействия:

▫️ что передаём — команду или событие
▫️ сколько получателей должны обработать сообщение
▫️ нужно ли хранить и повторно читать историю
▫️ важны ли маршрутизация, приоритеты и срок жизни сообщений


Разберём по полочкам 👇



🐇 RabbitMQ

RabbitMQ хорошо подходит для передачи команд и фоновых задач, которые должен выполнить конкретный обработчик:

▫️ отправить подтверждение заказа
▫️ зарезервировать товар
▫️ сформировать счёт
▫️ запустить расчёт

Обычно одна задача попадает в очередь, а выполняет её один из свободных обработчиков.

RabbitMQ стоит рассматривать, если:

✅ сообщение предназначено одному исполнителю
✅ нужна гибкая маршрутизация по разным очередям
✅ срочные задачи должны обрабатываться раньше обычных
✅ сообщения требуется удалять после истечения заданного срока
✅ нужны подтверждения обработки, повторные попытки и отдельная очередь (dead-letter) для сообщений, которые не удалось обработать
✅ после успешного выполнения задачи её не потребуется читать повторно.

Оговорка: fanout/topic exchange в RabbitMQ умеет доставлять одно сообщение сразу нескольким независимым очередям — так что «один исполнитель» это типичный сценарий использования, а не жёсткое архитектурное ограничение.



🔥 Kafka

Kafka подходит для передачи бизнес-событий — фактов, которые уже произошли:

▫️ заказ создан
▫️ оплата подтверждена
▫️ заказ отменён
▫️ доставка завершена

Одно событие могут независимо обработать несколько систем.

Например, событие «Заказ создан» получают:

📦 сервис склада — резервирует товар
💳 сервис оплаты — создаёт платёж
🔔 сервис уведомлений — сообщает пользователю
📊 аналитическая система — обновляет показатели

Kafka стоит рассматривать, если:

✅ одно событие нужно нескольким независимым получателям
✅ события необходимо хранить и перечитывать
✅ новый получатель должен обработать ранее опубликованные события
✅ по истории событий потребуется восстановить состояние сервиса
✅ данные используются для аудита, аналитики или отслеживания изменений
✅ система обрабатывает большой непрерывный поток событий.

Оговорка: хранение в Kafka не бесконечное по умолчанию — период (retention) настраивается отдельно. Если нужно хранить события вечно (что не хорошо для Kafka) — это отдельное архитектурное решение (compacted topic), а не поведение "из коробки".




👉 7 вопросов перед выбором

1️⃣ Передаём команду или событие?

«Выполни действие» → чаще RabbitMQ
«Действие уже произошло» → чаще Kafka


2️⃣ Сколько получателей должны обработать сообщение?

Одну задачу выполняет один из доступных обработчиков → RabbitMQ.
Каждый вид получателей должен независимо получить событие → Kafka (либо RabbitMQ через fanout-exchange, если история не нужна)


3️⃣ Нужно ли перечитывать историю?

Если после успешной обработки сообщение больше не требуется → RabbitMQ.
Если сообщения нужно хранить, повторно обрабатывать или передавать новым получателям → Kafka


4️⃣ Нужна ли сложная маршрутизация?

Очереди, правила маршрутизации, приоритеты и срок жизни сообщений — сильные стороны RabbitMQ.

В Kafka распределение строится через темы, разделы, ключи сообщений и группы получателей.


5️⃣ Важен ли порядок событий?

Kafka сохраняет порядок только внутри одного раздела. Чтобы события одного заказа обрабатывались последовательно, в качестве ключа можно использовать идентификатор заказа.

В RabbitMQ на порядок могут повлиять несколько обработчиков, повторная доставка и приоритеты.


6️⃣ Что важнее: распределение задач или история событий?

Распределить задания между исполнителями → RabbitMQ.
Сохранить поток событий для нескольких систем → Kafka.


7️⃣ Готова ли команда поддерживать выбранный брокер?

▫️ инфраструктура
▫️ опыт команды
▫️ требования к отказоустойчивости
▫️ стоимость сопровождения
▫️ возможности мониторинга



👉 В одной системе можно использовать оба брокера.
Но только тогда, когда системе действительно нужны обе модели взаимодействия.


#АрхитектураGA