I agree that a request-response model can be quite ergonomic for concurrency. I've used this pattern in quite a few Rust projects in a somewhat ad-hoc manner.

It's a bit like having a system composed of microservices (nanoservices?) that communicate via function calls.

It sounds a lot like the actor model, but I always found the classic architecture too limiting: requiring every actor to be a single-threaded message processor, instead of being able to handle requests concurrently. It's not too different from classic object-oriented design either, with singleton services.

In some project I've called my concurrent services Gods just to have a bit of fun with it :)