Почему не использовать REST API вместо брокера очередей для надежной передачи задач

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

Понимаете ли вы, что даёт брокер помимо слова «асинхронность», и готовы ли назвать цену этого выбора. Ответ, где у брокера одни плюсы, звучит как пересказ статьи.

Как отвечать

Синхронный вызов связывает участников по времени: обработчик недоступен, и задача теряется вместе с запросом, а вызывающий висит в ожидании. Брокер эту связь разрывает. Сообщение лежит в долговечной очереди, потребитель забирает его, когда готов, и подтверждает обработку. Отсюда четыре свойства, ради которых его и берут: переживание недоступности потребителя, сглаживание пиков за счёт буфера, масштабирование числом потребителей, повторы и очередь недоставленных сообщений для того, что не обработалось.

Сразу оговорить условия, иначе надёжность остаётся на словах: сообщения и очередь должны быть объявлены долговечными, нужны подтверждения публикации, подтверждение потребителя после работы, а не до, ограничение числа попыток и отдельная очередь для битых сообщений. Гарантия при этом остаётся «хотя бы один раз», то есть обработчик обязан быть идемпотентным.

И назвать границу честно: REST уместен, когда нужен немедленный результат, когда операций немного и важен простой контракт с трассировкой запроса. Надёжность на REST добирается руками через таблицу задач в базе, transactional outbox, ключ идемпотентности и повторы с выдержкой. Это работает, но в какой-то момент вы обнаруживаете, что пишете свой брокер.

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

Обещают доставку ровно один раз. Массовые брокеры дают «хотя бы один раз», а единственность получается только из идемпотентности обработчика или дедупликации по ключу на стороне потребителя.

Считают, что сообщения переживут перезапуск сами по себе. Без долговечной очереди и persistent-сообщений содержимое пропадает вместе с узлом, и «надёжная передача» оказывается разговорной фигурой.

Ставят знак равенства между RabbitMQ и Kafka. Первый раздаёт сообщения потребителям и удаляет после подтверждения, второй это лог со смещениями и сроком хранения, где можно перечитать что угодно, но нет привычных приоритетов и выборочного подтверждения отдельного сообщения.