3 ms·
I've solved this problem by adding a status field to my email objects/rows which can assume the values "Unsent, sending, sent, error". I guess it is a bit self-
by tedeh 7y ago
I've solved this problem by adding a status field to my email objects/rows which can assume the values "Unsent, sending, sent, error". I guess it is a bit self-explanatory, but status values are set like this:
- Unsent: Default status
- Sending: Message dispatched to broker
- Sent: Send task/message ack'ed
- Error: Send task/message any other exception
This of course assumes that your 5 000 emails are not ephemeral and are in a database.
If by "doesn't support any transactionality" you mean ack's aren't possible for one reason or the other then of course you have to go a slightly different route (pun somewhat intended) by publishing a "result" task/message and updating your database rows based on what comes back on this new "task_result" queue.
- machinecoffee 7y agoI guess the OP's point is that if you're storing everything on a db anyway i.e. 1 row per user,per email and a sent/not sent status flag against each row - then why do you need a messaging system? The email sending system could just poll the db for emails to be sent (by status=not sent), and then update the status after sending, as well as a timestamp for later cleanup. A more robust system is then achieved completely without messaging. Of course polling is never a great design, but I guess that's the crux of his question.
- ww520 7y agoPush vs pull, auto redelivery, scalable, distributed storage vs single DB.