> they are using an "async" system to simulate a thread-oriented system with blocking. You can do that, but why? The "simulation" is purely visual, or rather "

> they are using an "async" system to simulate a thread-oriented system with blocking. You can do that, but why? The "simulation" is purely visual, or rather "cognitive load reduction"-wise. It is explained multiple time throughout the pages om https://mats3.io https://mats3.io, for example here: https://mats3.io/docs/message-oriented-rpc/ https://mats3.io/docs/message-oriented-rpc/, and here: https://mats3.io/using-mats/endpoints-and-initiations/ https://mats3.io/using-mats/endpoints-and-initiations/ (with multiple examples, both pure Java and Spring-based definitions, also comparing to an ordinary REST controller). The clue is to be able to use the simple mental model of sequential steps, with "RPC calls" intertwined. However, this is only on a superficial level, to make the developer's reasoning simple and familiar - what really happens is that your Mats Endpoint is really multiple stages, where each stage is an independent little message processor. To achieve this, Mats implements "Messaging with a Call Stack", where you get a state object which "magically" follows you through the stages, simulating the stack variables you'd have if it actually was a proper method. It works surprisingly well. > That's a synchronous send message and wait for reply system, like REST. This you get if you employ the MatsFuturizer: https://mats3.io/docs/sync-async-bridge/ https://mats3.io/docs/sync-async-bridge/ This is a "tack on"-tool to the otherwise fully async nature of Mats/messaging. > For this to really work well, the message passing has to be integrated with the CPU dispatcher It sounds like you are 100% set on speed. This is not really what Mats is after - it is meant as a inter-service communcation system, and IO will be your limiting factor at any rate. Mats sacrifices a bit of speed for developer ergonomics - the idea is that by easily enabling fully async development of ISC in a complex microservice system, you gain back that potential loss from a) actually being able to use fully async processing (!), and b) the inherent speed of messaging (it is at least as fast as HTTP, and you avoid the overhead of HTTP headers etc. It is mentioned here, "What Mats is not": https://github.com/centiservice/mats3#what-mats-is-not https://github.com/centiservice/mats3#what-mats-is-not