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

например формирование большого отчета. нажал кнопку - хочу отчет. создалась заявка, положилась в очередь. в базу записалось, такой то юзер ждет такой то отчет. текущая стадия - ждем. юзер заходит и видит, мой отчет пока не начал делаться. когда начал - стейт меняется, заявка берется воркером в работу и 3 часа например крутится. юзер в это время видит  - мой отчет составлен на столько то %. когда он полностью готов - от уже видит "отчет готов" и кнопку скачивания. вот для этого очередь на бд идеальный вариант.

сюда же например создание титров к видео и прочее

А что мешает использовать очередь в данном случае?

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

Просто что ребит, что Кафка настраиваются определенными образами и имеют алгоритмы роутинга для распределенной обработки сообщений. А использование очереди на основе бд по сути в данном контексте ничего не меняет. С тем же успехом можно и рэбит тот же использовать для долгих заявок, но другое дело, что его правильно готовить нужно. А очередь на основании базы написать надо, чтобы не положить приложение и консистентно пуллить. Select-for-update накладывает свой оверхед

А разве для этого не лучше использовать какой-нибудь AWS Kinesis? Имхо, решать стримы через БД - это использовать решения 10-летней давности

+

Я пытаюсь понять мотивацию использования такого решения

Но пока не могу

можно. еще раз: тащить в систему ребит чтобы эту задачу решать  - оверкилл. он для другого. это то же самое что покупать ссд на 100 тб чтобы базу для интернет магазина с 1000 посещениями в сутки на пару сотен мб держать

Ну понятно, да. Просто есть готовые решения, упомянутый JMS. Подключается легко, настроек особых не требует, записывает все в файл (Artemis)

главный вопрос тут - сколько заявок в час / сутки поступает, и как обрабатываются.

да очередь на базе тоже не требует ничего, по сути добавил несколько строк в конфиг, миграцию накатил и все

И да, писать свою очередь на основании бд - не оверхед?

зачем ее писать если куча готовых решений с незапамятных времен уже есть?

А что вы использовали?

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

» с незапамятных времен

в этом вся проблема. потом мейнтенанс и эволюшен своих сервисов стоит дороже, чем использовать вендор. если нет в компании запрета использовать вендор - не вижу смысла отказываться от стабильных "из коробки" решений
Просто почитайте (особенно юз-кейсы и прайсы - сравните с зарплатой штата девопсов) https://aws.amazon.com/kinesis/

Сорри. Очереди - SQS больше (выше вроде про стримы говорили). Тут от задачи зависит, какой сервис нужен

ЗЫ: я не аппологет Amazon - уверен, у гугла тоже найдутся аналоги всех нужных вам решений. Просто так сложилось, что я знаю именно этот вендор

ЗЗЫ: да хоть стримы на дайнамо-дб (кому всё-таки хочется через БД упарываться) - я не знаю, какого решения я не найду у них

ну да, все так. есть 2 класса совершенно разных задач, решаемых через очереди
1) обработка потоков данных / заявок. сотни / тысячи  / ... в секунду
2) обработка редких но долгих и тяжелых заявок. построение отчетов, обработка файлов, парсинг сайтов, выгрузки из апишек. десятки заявок в час. ну максимум до десятков в секунду при нетяжелых задачах и большом кол-ве воркеров. тут же часто и крон используется. очередь нужна когда рандомные юзеры в рандомное время генерят эти задачи. ну или сама система. может быть не нужна очередь вовсе, достаточно крона.
кейсы со всякими кубер кластерами тут вообще не рассматриваю. про простые системы больше речь