Best practice for delaying jobs

Question

I have a system in PHP that works like a booking system. Once a booking is confirmed there are a total of 7 emails/sms that needs to be send. The times of when they need to be send are already known.

For example, 24h before the bookingdate, a email goes out.

Right now we have a cron checking if it is 24h< and the 24h email didnt go out yet, it shoots a job into the queue and the job tries to send the email, if it fails it retries etc..

How am I supposed to get a better grip on my notifications and be able to turn a single notification off or edit the content of the notification for that single booking? I am using a job-worker system that sends the notifications, I can only send them in the queue, when they are ready to be sent.

I was thinking of creating a db table called planned_notifications with all the content in it, a reference to the booking_id, and a send_after column

I can then remove a row in this table if I dont want the notification to be sent, or I can edit the content in this table to change the content of the notification

A cron is in place to take rows from the planned_notification table into the queue system.

I am probably not the first with this problem and am looking to get some info on 'best practices' for this type of problem

Answer 1

Your two main concerns here in high level design are essentially, the messaging from one or more software components to other software components, and flexible scheduling of jobs based on the age of a message event.

Some important considerations to make here are that you don't want to intermix what MQ messaging provides your system with scheduling or time sensitive events. So how do we start?

Create a Component Diagram

This will help you visualize and realize the various independent software components at play in your system. Keeping in mind that components should be loosely coupled with each other and independently testable, you should be able to identify what components belong. They should not take on more responsibility in the system than what is necessary.

For instance, a Booking? component should have the responsibility of creating and updating planned_notifications, however is taking on too much responsibility by also sending notifications and owning the business logic of when it is appropriate to send.

Component Interactions

When you decide on MQ Messaging, realize it is the glue that will tie your components together. In your diagram you can connect various components with Interactions, in this case the SMS/Email component can be sent a message that contains the details of the message to send, but it is important for SMS/Email component to not contain the business logic for determination of when a message should be sent.

It looks like your thoughts are already correct here. You shouldn't use MQ for data persistence. The need for a table is important.

High Level Design

If I were designing this system with this limited information upfront. I would create a booking component that schedules planned notifications in a table. The Scheduler component will contain a process that wakes up at regular intervals and identifies notifications to be sent, then formulating MQ messages with the details for the messages to be sent to a queue. A Notification component will read from the queue and own the responsibility for sending the notification.

In addition to this, some important things to consider are proper Exception Management. Any number of things can go wrong when sending an SMS or email, so you may want to consider an Acknowledgement queue that the Notification component can asynchronously provide a Success or Failure update message. Another software component may want to read these acknowledgment messages and update the database or logs accordingly.