Как спроектировать систему уведомлений (смс, почта и т.п.) для магазина?

Question

[Дмитрий]

Здравствуйте! Пользователи магазина генерируют различные события, типа новый заказ, смена статуса заказа, регистрация и т.п. На каждое такое событие нужно уведомить как пользователей, так и менеджеров. Уведомления могут быть разных типов, сейчас почта и смс, но в дальнейшем планируется использование мессенджеров.
У хендлера обрабатывающего смс, есть ограничение - отправка смс с 8 до 23 часов, если сообщение не попадает в этот интервал, то оно дожидается 8 утра и отправляется.
Из похожего по функционалу нашёл только https://github.com/namshi/notificator, ещё была идея использовать monolog для этого.
В общем виде схема видится такой. Клиентский код создаёт объект сообщения с необходимыми параметрами и передаёт его в менеджер, добавляющий сообщение (серилизующий объект) в очередь. Воркер, получая сообщение отдаёт его хендлеру для обработки.

Вопросы такие:
1. Каким образом правильно реализовать отложенную доставку смс по времени? Откладывать лучше при добавлении в очередь или на этапе отправки?
Есть идея завести отдельную очередь которая бы обрабатывалась только в нужное время. Получается, управление по времени будет осуществляться включением/выключением консьюмера. Размещение сообщения в конкретную очередь происходит на этапе добавления, в менеджере. Такой подход имеет право на существование или есть идеи получше?
2. Вопрос перекликается с предыдущим. На одно событие может быть несколько сообщений одного типа (смс например), но с разными параметрами. Всю логику обработки этих параметров нужно убрать в хэндлер или что-то можно оставить в менеджере (например распределение сообщений по физическим очередям).
3. Как понять, какие параметры должны быть у каждого сообщения в отдельности, а какие можно указать при создании экземлпляра хэндлера? Например, смс сообщение может быть отправлено как в кириллице (utf-8), так и латиницей, но добавляется изначально в кириллице. Параметр о том нужно ли его конвертировать, может быть как у сообщения, так и у самого хэндлера.

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

Answer 1

[Максим Федоров]

1. Правильнее что бы за отложенные сообщения отвечал сам сервер очередей. Если конечно Ваш сервер очередей не поддерживает отложенные сообщения нужно "химичить", вот например одно из возможных решений для RabbitMQ.
2. Думаю уместнее было бы разместить логику обработки параметров сообщения в хендлере
3. Ну тут так и не ответить, нужно понимать какие параметры есть, а потом уже думать как их распределять. Но в общем случае что мешает сделать настройки параметров как в хендлере так и в сообщении?

Comments

[Дмитрий]

1. Спасибо за ссылку. Очереди действительно RabbitMQ. Нашёл ещё несколько способов сделать доставку сообщений из очереди к воркеру ко времени.
2. Согласен. Но даже предположить, что все сообщения откладываются на один и тот же промежуток (ситуация из статьи), получается нужно реализовывать логику размещения в разных очередях в менеджере, при отправке сообщения из клиентского кода. Получается хендлер вообще может не знать что сообщение было задержано - он его получил и отправил. Или что-то упускаю?
3. Понял

[Максим Федоров]

Дмитрий: по второму пункту - да, он должен просто отреагировать на событие и произвести заданные действия