Hi Tim,
I use the task queue in order to retrieve results from REST services. I retrieve from Service Now a list of all CI items. The CI get details call I run in a TQ. 1). Not to choke the REST service (progressive time-outs) 2). Not to consume valuable resources from the Mx application. Important for my application is that I don’t need the exact data instantly in the process I’m in. In some of my applications, I indicate the time stamp of the last a-sync update.
Your example to send out (bulk) mail or other communication like SMS, I would give to the Task Queue. Important is to create a redo list. This list should be re-run (in case of technical failures) or processed (in case of functional problems). In your email example, the re-run or process should be based on the error received (bounce unknown = process, full mailbox would = re-run on a later time stamp).
The rules I use are:
1). do I need the outcome of the task in the process, I would wait for it.
2). if the timing is not important, I would consider giving it to a TQ, when error handling (both technical or functional) is possible.
3). when error handling is not possible, is a full rerun possible? If not, again don’t give it to the TQ.
4). Consider the communication type. Email is a-sync by nature, so ideal to process in TQ. But if you need to send an OTP pass via SMS, waiting 5 minutes on the position in a TQ could break the UX.
Just my brain dump for now. I hope others write here too. Maybe I should create a blog for it.
Did this help?