So you want to know about the Actor Model

I’m starting on a new project, and the team works with the actor model. I had never even heard of the actor model, and while I understood what the actors do in that system, I decided I needed to learn more about the theory behind it. And since I like sharing my knowledge, I’ll try to explain to you what I learned!

What is an actor, exactly?

An actor is an abstract entity which contains:

• Code to execute,
• A private state,
• Has a mailbox,
• And can send messages to other actors

It’s the most primitive unit of computation.

Every actor can have multiple addresses where other actors can send messages to, and behind one address there can be multiple actors. There’s a many-to-many relationship between the two. Actors are also completely isolated from each other and don’t share any state.

Ok, ok, but what does it do?

The actor model is a conceptual model to deal with concurrent processing. It does this by having several actors at the same time. One actor is no actor. One actor can only execute one message at a time, so to take advantage of the model, you need multiple actors working concurrently. One actor completes the messages in his mailbox on a First In First Out basis.

When an actor receives a message, it can do three things:

• Create more actors
• Send asynchronous messages to other actors
• Define what its state will look like for the next message.

It doesn’t matter whether the actor runs locally or on another node, as long as we can make the message get there. An actor can also only send a message to an address it knows, and it doesn’t know which actor(s) is (are) behind it. It knows the address of actors it created, and it can receive more addresses in a message.

Why use it?

With the actor model you can create fault tolerant or self healing systems. The actors that created other actors supervise their created actors, so they can restart them or send their messages to other actors.

There are also some other pros:

• Easy to scale
• No shared state
• Distributed computing
• Easier to reason about
• Enforce capsulation without resorting to locks

Of course there are also some cons:

• Deadlocks on the messages are possible
• Mailbox can overflow

If you are building a distributed system which handles tasks asynchronously, the Actor Model can actually simplify your code. If your tasks need to run sequentially rather than concurrently however, it might not be the best model for you.

Conclusion

I hope I understood the model correctly and managed to explain it to you in a readable manner. If you think I misunderstood something or missed an important part, please let me know in the comments! I would love to hear your thoughts.