Good question Tyson, there is no way in our fast-moving environment to get these values 100% "accurate" anyway (at least not with some sort of state sharing as we used to have it), so the sharding loadbalancer doesn't even try. Instead, the limits are divided among the controller evenly. On top of that, 20% slack is added to accord for round-robin imbalances in front of the controller.
If a user for example is allowed to invoke 1000 actions concurrently and we have 2 controllers in the system, we're giving 20% slack (1200 invocations) and divide that by the number of controllers (1200/2 = 600). Each controller now allows for 600 invocations concurrently. With round-robin in front of them that should in practice be enough to roughly maintain the limits as today. Does that help? Cheers Markus
