How to organize the work of notifications on the service?

Question

PHP

There is a need to send notifications to the user depending on the states of the objects.
Now there is a cron script that checks the status of objects and sends the necessary notifications. At the same time, after sending, it sets a flag for the object that a notification of this type has been sent. I don't think it's very pretty. How can the problem be solved differently? Maybe there is some pattern? Only the creation of a separate common table with all notifications or a separate one for each entity comes to mind.

Answer 1

I don't think it's very pretty.

1) when the state of an object changes, throw an event about it or explicitly call a notifier
2) the notifier adds a task to the queue (beanstalkd, rabbitmq, etc)
3) the queue is responsible for tracking the status of the task
4) workers take tasks from the queue and actually send them.

Answer 2

This is a state trigger.
Entities: alert, channel (alerts), delivery status, processing status, retry time, number of retries
An instance of the "alert" entity is created by the trigger and assigned to the "channel".
Further, the channel worker (each worker for its own channel and they are synchronous):
1. picks up a notification packet of N-pieces and puts down the status: sending
2. tries to send.
3. when everything is processed - puts down the processing status, according to the processing (success,fail,retry + sendAt:timestamp + retryCount++ - adds to the queue itself)
4. When everything is sent - proceeds to fetch the next data packet.
If it is possible to check the delivery, the field is changed using the incoming delivery event (the delivery channel protocol is responsible for this).
5. After successful processing of the notification (statuses are all success), you can either simply "kill" the notification from the queue or place it in the notifications archive table (if the business process requires it).