What kind of feature are you missing? Where do you notice a shortcoming of PTB?

SettingApplicationBuilder.concurrent_updates(True) allows to process all updates concurrently (up to a specified number at a time). What you can't do is e.g. processing updates from all users & chats concurrently while processing the updates for each user/chat sequentially. Having the possibility for such a mechanism would e.g. allow to

• handle updates concurrently except those that are revelant for stateful handlers such asConversationHandler
• apply a rate-limiting mechanism for users by delaying processing of their updates
• prioritizing certain types of updates for handling, e.g. inline/callback queries over regular messages

Describe the solution you'd like

1. Introduce an interface classBaseThrottler (other naming suggestions are welcome!). This class should
   1. accept an integer that specifies the maximum overall number of updates that may be processed concurrently
   2. have a single abstract methodasync def process_update(update, coroutine) whose task it is toawait at an appropriate time, that may be determined depending on theupdate
   3. have a single non-abstract methodasyne def do_process_update that callsprocess_update after applying a global semaphore, which enforces the limit in a.
2. Introduce a classSimpleThrottler(BaseThrottler) (other naming suggestions are welcome) for whichprocess_update immediately awaits the coroutine, i.e. does not apply any additional throttling
3. The behavior ofApplication.concurrent_updates(…) should be as follows:
   1. passing an int will make use of theSimpleThrottler with the respective max overall number of concurrent updates
   2. passingTrue will behave as a. with the current default number specified for that case
   3. passing an instace ofBaseThrottler will use that instance for handling concurrency
4. Application.concurrent_updates should return the max overall number of concurrent updates as specified for the throttler in use. The throttler itself may be made available via an additional attribute/property

Describe alternatives you've considered

• Instead of an interface class, one could directly provide theSimpleThrottler and encourage users to overrideprocess_update
• One could makeSimpleThrottler a bit more elaborate by e.g. allowing to sequencify the processing of updates per chat id. In this case, I would vote to go for the interface-class approach as the implementation would surely require more elaborate internals than that ofSimpleThrottler.

Additional context

This idea was already discussed a bit in the early stages of the v20 architecture design but was put on hold, since we first wanted to get the basic structure ready before introducing additional functionality.

Before an attempt on an implementation for this is made, I'd like to get feedback on the idea :)