REMINDER
High Volume Email sending - rate limiting? Queueing?
-
Hello team,
I'm writing a CloudBackend function to send a high volume of emails (about 1850 in the space of a few minutes).
My function successfully calls and gets a resolved promise from the cloudBackend.sendEmail function.... but the emails can sometimes take 20, 30 minutes to arrive.
This was confusing during testing, as I re-launched the sends after tweaking the code, and ended up with many, many, many emails in my test inbox
Can you please tell me what kind of throughput I should expect from the .sendEmail function? How can I be sure that it will send (am I guaranteed a send attempt if the .sendEmail promise returns resolved?)
Daniel
-
Hey Daniel,
Email sending rate will match your cloud backend offer (max API calls per minute)
So if you have a Large backend you can send up to 1000 transactionnal emails per minuteYou should watch the promise response to ensure the response is OK and not KO, it should always be OK except if the email is invalid or if you are over quota.
FYI unlike in the newsletter module, for transactionnal emails we don't have yet a webhook delivery channel to notify you for deliveries/bounce/complaint.
If you really need that feature now I recommend you to use an external service (AWS SES, Sendgrid, ...) for that part and use it from your cloud function
-
Thank you for all that additional information.
When I tested, I was indeed able to send 1000 emails in one minute, however the emails were not 'received' all at once - they seemed to 'trickle' in over 30, 40 minutes.
Is this Amazon SES or your system queueing the outgoing traffic? Or the recipient server doing the same thing?
-
Amazon has a default of 28mail/second when raising the limit one time, can be extended to much more than that.
But I'd assume that Appdrag throttle the send-out queues.
-
In fact when you get our confirmation we have transmitted it to AWS SES already and it was accepted in their queue,
AWS or the target email servers might build queues based on volume per origin/target.So answer is we don't queue your messages but AWS might do it
-
@Joseph-Benguira Right, forgot that AWS have to stay within e-mail provider limits.
-
Thank you both Thomas and Joseph for clearing that up! The 28/sec. seems about right.
@Joseph-Benguira does each AppDrag account have its own SES queue? Or does that 28/sec. rule apply to all AppDrag customers at once?
-
In fact we have a much larger allowance on AWS SES (few hundreds per sec) and it's shared by all appdrag customers.
I'll check but I don't think we have any hard limit per user on our side.
