How to design a notification system (sms, mail, etc.) for a store?

Question

PHP

Hello! Store users generate various events, such as a new order, order status change, registration, etc. For each such event, both users and managers need to be notified. Notifications can be of different types, now mail and sms, but in the future it is planned to use instant messengers.
The handler processing SMS has a limitation - sending SMS from 8 am to 11 pm, if the message does not fall within this interval, then it waits until 8 am and is sent.
From similar in functionality, I found only https://github.com/namshi/notificator, there was also an idea to use monolog for this.
In general, the scheme looks like this. The client code creates a message object with the required parameters and passes it to the manager, which adds the message (the serializing object) to the queue. The worker, receiving the message, gives it to the handler for processing.
The questions are:
1. How to correctly implement delayed delivery of SMS in time? Is it better to postpone when adding to the queue or at the stage of sending?
There is an idea to have a separate queue that would be processed only at the right time. It turns out that time control will be carried out by turning on / off the consumer. The placement of a message in a specific queue occurs at the stage of adding, in the manager. Does this approach have a right to exist or are there better ideas?
2. The question echoes the previous one. For one event, there can be several messages of the same type (sms for example), but with different parameters. All the logic for processing these parameters must be removed in the handler, or something can be left in the manager (for example, distributing messages among physical queues).
3. How to understand what parameters each message should have separately, and which ones can be specified when creating a handler instance? For example, an SMS message can be sent both in Cyrillic (utf-8) and in Latin, but it is added initially in Cyrillic. The parameter about whether it needs to be converted can be either in the message or in the handler itself.
Perhaps you have seen ready-made solutions that solve similar problems, I will be grateful if you recommend.

Answer 1

1. It would be more correct that the queue server itself would be responsible for deferred messages. Unless, of course, your queue server does not support deferred messages, you need to "chemize", for example, here is one of the possible solutions for RabbitMQ .
2. I think it would be more appropriate to place the logic for processing message parameters in the handler
3. Well, there’s no answer here, you need to understand what parameters are, and then think about how to distribute them. But in the general case, what prevents you from making parameter settings both in the handler and in the message?