Сервис очереди, или как подогнать код под все случаи

[Vanirn]

Зачем создавали кастомную очередь, при наличии Channels или ConcurrentQueue?

[Ingini]

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

[posledam]

По-моему в наше время делать очереди на БД это просто банальная и не нужная трата времени. Можно взять, например, RabbitMQ, и спокойненько настроить топологию любой сложности, запустить сколько угодно консюмеров (1 или несколько) под разные очереди с нужным QoS, дедлеттерами и автоматической переотправкой, плюс гарантии доставки, распределение по нескольким экземплярам приложений и прочее, включая возможность подписки на любые событие любым левым сервисом, мониторингом, или даже при большом желании отдельная очередь на эксчендж для сброса всё в БД. Или можно взять NATS, Kafka если событий дофига и надо очень быстро их обрабатывать.

В случае необходимости локальной обработки очередей, то тут выбор очевиден: Channels. Тоже нет смысла городить огород, разные виды тротлинга, скорость, graceful закрытие канала и прочее.

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