P@Engineering, I think even combination of digest and delay don't solve this use case
DI like to ping @dimagrossman and @omerbenami instead more a feature request.. Because we do not have anything that solves this today.
PYes @Konrad
P!feature
Z@Konrad I would assume that you would be using our Custom SMTP connector correct?
N@Konrad, you just advanced to level 1!
ZDo you have a sample of what mailgun and the custom smtp send back as a rate limit response?
ZThank you, if we know there is a standard responce back then we should be able to build this relatively quickly.
DThank you @Konrad this information really helps, and you are onehundred percent correct, we could potentially hit the same problems with a rate limit for sendgrid for example for high thruput usecases.
A small question if you know that, will outlook respond with standard rate limiting headers that will indicate how much left for the rate limit and when it will be renewed?
We could try using the retry functionality from our queue in case of rate limit to retry exponentionally, but this is not bullet proof specifically in your usecase where you want to send that many events.
I guess we would some how need to manage a queue throttling based on environmentId + providerId and make sure we are not processing more than the limit of the provider (we can easily write all provider limits in a configuration file based on public docs of theirs) .
@zacclifton do you have any ideas on how we can achieve this with the existing system relying on a queue and managing a central state of current rate limit status per provider and organization?
A small question if you know that, will outlook respond with standard rate limiting headers that will indicate how much left for the rate limit and when it will be renewed?
We could try using the retry functionality from our queue in case of rate limit to retry exponentionally, but this is not bullet proof specifically in your usecase where you want to send that many events.
I guess we would some how need to manage a queue throttling based on environmentId + providerId and make sure we are not processing more than the limit of the provider (we can easily write all provider limits in a configuration file based on public docs of theirs) .
@zacclifton do you have any ideas on how we can achieve this with the existing system relying on a queue and managing a central state of current rate limit status per provider and organization?
DAnd also @Konrad out of curiosity, are you able to setup a second SMTP connection so Novu can load balance the requests between the two 
ZThe way I would solve this is we would delay the message for the specified amount of time, give that message priority, and send it again when we rate limit is lifted.
In terms of digest, if the message is a digest message then I would send the messages back to the digest and mark the the next digest send as a higher priority.
As for provider limits, I agree that we could write them in the providers however different providers provide different rate limiting per level. We would need to look at a way to adjust for this.
In terms of digest, if the message is a digest message then I would send the messages back to the digest and mark the the next digest send as a higher priority.
As for provider limits, I agree that we could write them in the providers however different providers provide different rate limiting per level. We would need to look at a way to adjust for this.
Z@Konrad Just wanted to follow up and see if you where able to find how Outlook throttled you