Delay sending an email using Mandrill send_at or Celery countdown/eta

Question

I commonly send transactional emails in response to certain actions on my website, some of which I delay sending by a couple of hours. The function that actually queues the email is a Celery task function called with .delay() that eventually makes an API call to Mandrill using djrill .

I discovered that Mandrill offers a send_at parameter when sending an email that will have Mandrill delay sending the email until the specified time. Celery also offers eta or countdown parameters when calling apply_async() or delay() on a task, which will have the Celery worker wait X amount of time before executing the task—which here, would amount to the same thing.

Ignoring cost, which approach is architecturally preferable—having Celery delay queuing the email using countdown , or sending the email to Mandrill immediately but with a send_at parameter so Mandrill waits for me? What factors should I be considering when making this decision?

Answer 1

I'll share some points we could have into account to make a choice here:

1. Fault tolerance : if we give this responsibility to Celery, then we could be more prone to fails, since if the message queue (Rabbitmq, ZeroMQ or whatever ), the machine or the Celery itself fails then the email will never be sent. Mandrill could fails as well, but probably in minor grade.

2. Maintenance : What about if you need to change Celery for something else? In this case you need to migrate the code and probably, to spend some time to figure out how to do this scheduling in the new MQ tool.

3. OOP : From the point of OPP, we might see Mandrill as an entity that sends emails, which brings several features, eg scheduling, so let's consume this external service from our system, let it do it its work!

4. Usability and Scalability : Think on an hypothetical situation where you need to run your system in more than one server simultaneously, due to growing performance requirements; which is the easier and more efficient way to handle this scheduling?

These are not all the aspects that should be considered to make a decision, but certainly are some that should not be missed. Hope that helps to figure a better/solid solution.