@Ague yep, I agree with you. This RFC does not help your use case much, since the majority of the events you’re listening for aren’t for users of your application.
I just want to highlight one of the (probably obvious) reasons why we have limits: Most third-party developers are good actors and we want to continue helping them grow. However naturally there are some bad actors too. And sometimes it’s difficult to tell whether they’re a good actor or bad actor without scrutiny. And sometimes good actors later become bad actors. We review applications, but in reality we should create a system that deters bad actors in the first place.
I don’t want this conversation to turn into “but what is good and what is bad” (someone is going to quote the infamous line from Hamlet). I just want to paint a picture that there are conflicting interests at play. And in the past we solved this by enforcing static thresholds on every developer that constantly had to be reviewed and adjusted by a human.
When designing this RFC, the goal was to create a strategy that we were confident would benefit the vast majority of good actors while not encouraging bad actors. It was tremendously hard to strike the right balance, and we considered dozens of approaches.
We settled on the above RFC, realizing that it would benefit the majority of good actors, but not all of them. Please don’t think we were neglecting your use case – we were just trying to strike a difficult balance. This is why we made the max_total_cost field adjustable. For good actors that don’t benefit from this RFC, we adjust max_total_cost (as you mentioned, you already benefit from this).
Lastly, I just want to mention that the proposed strategy isn’t taking away your ability to scale. We’re not suddenly reducing the number of subscriptions developers can create. We’re merely auto-scaling subscriptions where we’re confident it’s safe to do so.