Нечасто пишу про логику выбора в реальной деятельности, но тут пришлось: после шутки про HH как очередь в Redis появились замечания про техническую неточность. Так что внесу ясность.

Почему не часто? Потому, что в группе с IT-шниками говорить про IT-решения мне лично напоминает диалог двух терапевтов, которые вечером за бутылкой водки обсуждают кто из пациентов как чихает. Ну серьезно...

Ладно, что там с разницей и выбором было? Давайте определимся.

Разница между Redis и брокерами Kafka, RabbitMQ - не в скорости, а в гарантиях. К слову, NATS, Pulsar и прочие SQS оставим в сторонке, а то Талмуд будет, а не прояснение позиции.

Redis List (LPUSH, BRPOP) - простая очередь: быстро, но без гарантий. Воркер взял задачу и упал - задача потеряна. Никаких подтверждений, повторной доставки и мёртвых очередей. Это как раз то, что я обыгрывал в сатире: кандидат потерян - и ладно. Redis List чистой воды.

Kafka - это журнал коммитов с репликацией: сообщения хранятся долго, их можно перечитать, есть реплей, горизонтальное масштабирование. Подходит для больших объёмов и строгих гарантий.

RabbitMQ - очередь с гибкой маршрутизацией, подтверждениями и мёртвыми очередями. Классика для сложных сценариев доставки при умеренных нагрузках.

И отдельно давайте вспомним про Redis Stream: это уже не просто List. Он даёт группы потребителей, подтверждения, список ожидающих и повторы - почти как брокеры. Но персистентность асинхронна: есть окно, когда данные только в памяти. Если Redis упадёт до записи на диск - часть сообщений пропадёт. RPO не нулевой. Это принципиальное отличие от гарантий Kafka. Хотя... appendfsync always как помнится сводит PRO к нулю, но это ладно.

Почему тогда Redis массово используют как очередь? Потому что он уже стоит - как кеш. В том же Laravel (PHP) Redis - драйвер очереди из коробки, в BullMQ (Node.js) де-факто работает поверх Redis Stream. Добавить очередь - одна строчка в конфиге. Поднять Kafka - отдельный кластер, мониторинг, обучение команды.

Операционная реальность часто важнее «теоретической правильности».

Когда Redis уместен:

лёгкие фоновые задачи (email, SMS, push), где потеря не критична; сценарии реального времени с низкой задержкой; проекты без ресурсов на отдельный брокер.

Когда Redis - ошибка:

финансы, биржи, где потеря сообщения = потеря денег; высоконагруженные пайплайны с необходимостью реплея; сложные схемы маршрутизации с гарантированной доставкой.

И отсюда та самая параллель с HH. HH - это как Redis List: быстро, просто, без гарантий. Пакет вытащили и забыли. Кандидат выпал - никто не вернёт. Это не баг, а следствие выбранной архитектуры: HH - не брокер для людей, а кеш для резюме.

Когда говорят, что Redis для очередей не подходит, - в абсолютном смысле это правда: у него нет гарантий брокера. Но без контекста задачи эта фраза ничего не значит. Выбор инструмента - не про «правильно/неправильно», а про соответствие требованиям. Если нужно быстро и просто - Redis подходит. Если нужна гарантия - тогда Kafka или RabbitMQ.

Главный вопрос тут не в Redis, а в том, что мы строим и какие гарантии нам реально нужны.