Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature Request: allow send rate per channel #281

Open
jgrammen-agilitypr opened this issue Sep 26, 2024 · 2 comments
Open

Feature Request: allow send rate per channel #281

jgrammen-agilitypr opened this issue Sep 26, 2024 · 2 comments
Labels
enhancement New feature or request

Comments

@jgrammen-agilitypr
Copy link

Feature Request

allow users to set a send rate (throttle) a particular channel.

Use case: if you are using a sms provider to provide notifications (like aws sns) you might have a send rate limit that you would like to enforce on a particular type/channel of notifications. This might be 1 message per second, or 100 messages per second.

@oxzi oxzi added the enhancement New feature or request label Sep 26, 2024
@oxzi
Copy link
Member

oxzi commented Sep 26, 2024

Thanks for coming forward with this request.

How do you think implementing this makes more sense? Reducing the throughput after a certain amount of messages and then working on the backlog with more delay or capping the amount of messages within a time frame, dropping the surplus messages?

While the first possibility stops bursts, it will not reduce the costs of those messages, speaking about SMS, for example. The second option may result in hiding relevant information, but otherwise one can assume that the responsible on-call person already checks the monitoring after the phone rang ten times. This second option may require another special message to be sent, indicating that within the next time interval notifications are being reduced, similar to syslog's "last message repeated N times".

Or do you have another idea? Specially for your use case, what would work best?

@jgrammen-agilitypr
Copy link
Author

the first option was what I had in mind ("Reducing the throughput after a certain amount of messages and then working on the backlog with more delay"). basically messages that exceed the throughput/rate limit are queued for delivery.
this means the user will get all the messages without ever exceeding the rate limit.
This is not a cost optimization, it is preventing phone numbers or senders from keeping flagged or blocked due to exceeding the rate limit.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants