I mean that is orthogonal to whether you are using messaging or not.
With API calls you default to doing them in order but you can certainly multithread the calls and lose the deterministic order if you want. With messaging you default to sending them off in parallel and not knowing which are received / processed / completed before the others, but the non-default is available there too. You have a message router that knows what has to be ordered and what doesn't and manages the flow. In both cases the non-default requires a bit more work but in both cases it's available and it just depends what your most critical needs are.
One thing though is that as systems scale up and get more complex, you want less and less to have blocking API calls anywhere that you don't need them, as those quickly become your bottle necks and hard failure points.
With API calls you default to doing them in order but you can certainly multithread the calls and lose the deterministic order if you want. With messaging you default to sending them off in parallel and not knowing which are received / processed / completed before the others, but the non-default is available there too. You have a message router that knows what has to be ordered and what doesn't and manages the flow. In both cases the non-default requires a bit more work but in both cases it's available and it just depends what your most critical needs are.
One thing though is that as systems scale up and get more complex, you want less and less to have blocking API calls anywhere that you don't need them, as those quickly become your bottle necks and hard failure points.