Hmm. To be honest, I don't know if I like this more than the way it was before. Now, in order to understand the code, one has to "follow the functions" and move back-and-forth between the function definitions and the places that they are called, all in the same file.

The SonarQube metric of "Cognitive Complexity" seems to be flawed in itself, to say the least. The method in question is defining a pekko Behavior and is itself divided into sections of handling different types of messages. But even if a method is just that long, it doesn't have to be a bad thing to me.

One way to (arguably) more accurately represent the involved complexity is, in my opinion, using the concept of (for a lack of a better name) "DataCores" that encapsulate the data storage and processes involved with the data. It's what I used when modeling the new scheduler and EmAgent. This way, the code could maybe be simplified a bit. However, this suggestion should be taken with at least a grain of salt, as I might be a bit biased towards it.