I see, I think it's a interesting design choice but I think can be a bottleneck as we are first limiting all app requests to be processed one at a time for a central actor, then another serialize access to dispatch a future. 
You can also achieve the exact same thing by having the app actors themselves each hold a future and return action in progress back. 
If the current design holds our scale target then I don't think we need to do this change (or very least not this PR).