а не проще послать по крону? Так как если что-то случится в период между отправкой и началом обработке может сообщение потеряться, если этот период времени будет большим.

Дочитай доку до конца. Там пишут про делэи.

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

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

Да, вот читаю про Stamps, спасибо.
Это выглядит менее костыльно, но как то всё равно немного не то. там делей в секундах - насколько я понимаю - от времени попадания сообщения в автобус/ Для дебага как то несовсем удобно, когда отложить нужно на насколько недель например. Но не критично, буду пробовать

транспорт хоть уточни какой

doctrine

Ну mq это все же такая вещь предназначенная для независимой связки нескольких сервисов/программ. И на сколько я помню популярные брокеры сообщений не всегда хранят все очереди на диске. Да там можно вроде все это настроить, но все же. И они не предназначены для хранение данных. А в вашем случае вы там собираетесь хранить данные на протяжении недели. И на сколько я понимаю очередь будет пухнуть  в течении недели. Хотя можно сгенерить сообщение именно тогда когда надо их обработать и отправить их в очередь. А случиться с очередью может что угодно. в полоть до того что допустим место закончится когда очередь будет пухнуть. А если отправлять сообщения в момент когда надо их обработать, то отправка и обработка очереди будет идти параллельно.

в данном кейсе сообщения сохранить отдельно в таблице, а в месаджере получать списки с необходимыми фильтрами и отправлять

» А случиться с очередью может что угодно

Я не уверен, что правильно понял этот пример.
Если с очередью "что-то случиться" то это повлияет на все сообщения, а не только на те, которые с задержкой. Поэтому вопрос о том, чтобы с очередью ничего не случилось - думаю общий и отдельный.

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

Про крон пример понял. Похоже таки без него не обойтись (
Но не уверен, что понял первое сообщение.

Есть меседж и хендлер.
К примеру, я создают отдельную таблицу и храню в неё данные для обработки хендлером, чтобы не хранить данные длительно в меседжах.
Каким образом организовать работу? (без крона)
записи в таблице должны соотносится с меседжами один к одному?
Или как то иначе? И где именно должна происходить фильтрация?

Да это общая проблема. Но обычно все же там часто если идет потеря, то минимальная за счет того что очередь старается все же сразу отдать все сообщения. А когда там пухнут сообщения за неделю то там уже не минимальна, а восстановление очереди это тоже самое что и их заного сгенерить.

Должно быть не важно какой транспорт. Сегодня это одно, а завтра уже может быть другой. И реализация не должна зависеть от транспорта.

а еще не важно какая база да ведь мы каждый день меняем базы на проекте

ну то есть вот ты юзаешь один брокер - у него одни гарантии, можешь юзать рэдис - у него нет гарантий.

оч наивно думать что транспорт "должен быть любым"

Наивно думать, что смена никогда не произойдет. Проекты переезжают с одной базы на другую. Допустим для повышения производительности. Знаменитый пример Uber.

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

зачем соотносится? В хендлере инжектится em, из репо получаем список сообщений по фильтру, и отправляем, но!!! месанжер  - не планировщик, лучше это конечно переложить на крон: создаем комманду, в комманде получаем список, добавляем в очередь

почитай дискуссии в мэйлинг листе постгресса о проблемах из-за которых убер переехжал сначала с мускуля на постгрес а потом с постгреса на мускуль. ну и да - ты не убер)

в моей жизни мы переезжали на живом проекте с одной базы на другую один раз. Чаще такое можно встретить если "мы сейчас на оракл или mssql"