I'm building a reservation system in Rails 4.2 where I need to send a set of emails to users at predefined intervals (for example that they have an upcoming reservation, feedback after it's done, a link to change/cancel an existing reservation, etc.). I've looked around and found this and this , but I'm trying to decide between the approaches. I see two main ways of building this system out. Using a queue system like delayed_job . Whenever someone makes a reservation, we queue up all the emails for the correct time when they should be sent. Pro: One queue for all emails. Automatic retry logic. Con: Thousands of emails will eventually get queued in the system. Need to dequeue whenever someone cancels a reservation (dependent: destroy emails related to it might be pretty easy). Somewhat more complex logic around what time we need the emails to go out. cron + rake task that runs at some predefined interval (hourly? every fifteen minutes?) and checks for the emails that need to go out. It runs a query like "Find all reservations that are three days from now", and then sends out all emails. Pro: Put everything into application logic, reduce the amount of state we need to keep track of. Con: Need to keep track of which emails have been sent, which is conceptually similar to whatever jobs table we already have created above.

Reputation: 11385

Architecting a system for reminder emails

I'm building a reservation system in Rails 4.2 where I need to send a set of emails to users at predefined intervals (for example that they have an upcoming reservation, feedback after it's done, a link to change/cancel an existing reservation, etc.). I've looked around and found this and this, but I'm trying to decide between the approaches.

I see two main ways of building this system out.

Using a queue system like delayed_job. Whenever someone makes a reservation, we queue up all the emails for the correct time when they should be sent.

Pro: One queue for all emails. Automatic retry logic.

Con: Thousands of emails will eventually get queued in the system. Need to dequeue whenever someone cancels a reservation (dependent: destroy emails related to it might be pretty easy). Somewhat more complex logic around what time we need the emails to go out.
cron + rake task that runs at some predefined interval (hourly? every fifteen minutes?) and checks for the emails that need to go out. It runs a query like "Find all reservations that are three days from now", and then sends out all emails.

Pro: Put everything into application logic, reduce the amount of state we need to keep track of.

Con: Need to keep track of which emails have been sent, which is conceptually similar to whatever jobs table we already have created above.

Upvotes: 8

Answers (2)

Jay-Ar Polidario

Reputation: 6603

The one good advantage of 1) using delayed_job (or Sidekiq) is that you could update the schedule of a job (or a recurring job) from the site dynamically.

You can provide a page in your site to update recurring jobs. Now, delayed_job doesn't really allow recurring jobs by default. There are add-on gems that could be of interest though delayed_job_recurring or sidekiq-scheduler. If compute power is not a problem, I would always prefer an actual job processor rather than cron because it is just more manageable for me.

Upvotes: 0

Nicolas Maloeuvre

Reputation: 3169

Second approach is better (use heroku scheduler if on heroku), queues are more for "run as soon as possible" than "run at this particular datetime"

Upvotes: 1

Architecting a system for reminder emails

Answers (2)

Related Questions