There are situations where efficient rate controlling is an appropriate default behavior, for example when writing a library for an API wrapper. However, the user may want to override this behavior and let the requests pass through unboundedly again.

A solution for the author of the API wrapper library could be to accept None as the rate controller factory parameter, and handle the None case on every call they make to the rate controller.

This is far from ideal, so a better solution would be that we offer a NoopController (or whatever name fits best), that would match the RateController interface and do precisely nothing.

In order to optimize memory usage, such controller should be implemented as a singleton.

Sometimes, the ability to chain buckets does not suffice, and we would need to chain rate controllers. For example let's say that we work with multiple REST APIs at the same time, each of them using their own rate controller.

We can already chain a global bucket with each one of these buckets, using BucketGroups, for example if we would like globally to not send too many requests at once. However, if we would like to enfore global constraints, such as defining a global concurrency limit, well currently we cannot.

A solution, that has yet to be implemented, would be to share a global rate controller with no bucket but only this concurrency limit, and chain each of the individual rate controllers with it.