The gateway uses Rabbitmq with Masstreansit to send commands to services. Some of services require event sourcing in their internal architecture. Since I need my aggregate states available, and the system requires speed, The actor model seems to be a good fit, but require to deal with a couple of issues:

  1. The actors should acknowledge the command to be removed from the message queue for reliability purposes.
  2. Out of order commands should not be acknowledged to be resent to the actor(Optimistic concurency).
  3. Reading a command from one queue(rabbitmq) and writing it to another queue(actor model's mailbox) seems to be redundant.
  4. I'm going to use proto.actor and that seems to require remote cluster for sending commands to actors based on the id of the actor, and that means yet another unnecessary network layer after reading each command from message queue inside of my event sourced services.

And that complexity makes me uncertain about whether I am in the right path or not.

Am I in the right road?

Is there any alternatives to that solution?

Please help me to clarify the question with your comments if you find it unclear. Thanks.


The actor model is a conceptual model to deal with concurrent computation. It defines some general rules for how the system’s components should behave and interact with each other. The concept fits well with Event Sourcing application however due to the complexity to implement it´s worth to use it with a stable framework that hides the complexity and provides you an interface to interact. I suggest trying Akka Actors. In this talk the legend Carl Hewitt elucidates how the actor model works.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.