In the Discord case study, we saw how a distributed real-time system was built upon the Actor Model. Don’t be fooled, though; this model wasn’t invented at Discord. Instead, it’s a pattern from the 70’s that has become so fundamental to our concurrent systems that we rarely slow down to appreciate its genius.
What about the model is so special? There are entire books that explain this in detail. For this edition, we’re zeroing in on two core ideas: messages and mailboxes. These are the mechanisms that constrain each actor while preserving the power of the system.
Messages
The key to the actor model is messages, which are:
The bundles of data — typically objects — that actors pass between one another.
The inputs and outputs of every actor. Rather than sharing state directly, actors communicate exclusively through messages.
Immutable. Once a message is created, it cannot be changed. Think of it like sending a sealed letter: the recipient gets exactly what you dropped off, and no one can alter it in transit. This one rule eliminates an entire class of bugs.
What actually happens when an actor receives a message?
One of four things:
The actor updates its own state
It creates more actors
It sends a message to another actor
It changes its behavior (how it will respond to future messages)
That’s it. Four activities summarize every interaction in an actor-based system.
Actor messages are perfect for Domain Driven Design (DDD).
DDD models code around an org’s entities and rules. It’s a natural design for our sprawling distributed systems. Anywhere the business logic is rich, stateful, and central to the product, DDD tends to shine.
Actors are a natural way to implement DDD entities — the core objects that have identity and evolve. In classic DDD, these entities exchange one of four messages:
Command: Tells an actor to change state (”Process this payment”)
Event: Records that a state change happened (”PROCESSED”)
Query: Requests information (”What’s the current balance?”)
Results: Response to a query ($247)
Four rules that detail how nodes communicate. Sound familiar? The terms vary, but both the Actor Model and its DDD embodiment use communication as a constraint.
Mailboxes
Where do actors process messages? That’s where mailboxes come in.
A mailbox is like an in-memory queue attached to each actor. Messages arrive and wait their turn. The actor works through them one at a time.
The key point here is that the mailbox is separate from the actor. The actor doesn’t manage its own queue — that’s handled by the library (like Akka in Java) or by your own implementation.
This separation seems unintuitive at first. If there is only one mailbox for each actor, why add that abstraction in the first place?
Same reason why none of our email apps support tasks: delivering and processing are two very different jobs. This separation of concerns allows the mailbox to focus on delivering the message and the actor to focus on reacting to it. Practically, it also makes scaling the system easier, as actors and their mailboxes can exist in separate containers.
Bringing this together
The actor model comes with a powerful guarantee: state can always be updated safely. The actor itself can only access its own state; other actors can only request that state by sending a message; only one message can be processed at a time.
Even though actors are constantly communicating, state is mediated through messages. Nothing gets corrupted by a parallel operation.
This is only possible thanks to the addition of communication rules. These keep nodes independent enough to do their jobs, while keeping the system trustworthy enough to grow.
The Remote Company
Imagine you’re working at an in-person company that doesn’t believe in SaaS or documentation. All decisions are verbal. When there are five of you, that works fine — it’s actually kind of fun. Once there are fifty people, everything breaks down. Shared resources get locked up. It takes forever to get people aligned. Constant interruptions undermine productivity.
Then the company reinvents itself. It goes fully remote, mandates email-only communication, and bans multi-tasking. You work through your inbox, one message at a time. Suddenly, agendas are written, conferences rooms are reserved, and everyone gets updates. It’s less chaotic fun, but things are actually getting done again.
The communication rules were needed to ensure the system could flow again.
That’s the actor model.
Takeaways
Why does this matter?
As our systems grow more complex, one of the most valuable skills we can develop is recognizing elegant simplicity. Alan Kay put it well: “You get simplicity by finding a slightly more sophisticated building block to build your theories out of.”
The actor model is exactly that kind of building block. It doesn’t introduce an impressive new algorithm or chip architecture. Its genius lives at the transport layer. We’ve learned to obsess over the computation layer’s complexity at the expense of the simple solutions in plain sight.
The better we get at recognizing this kind of structural simplicity, the better we can protect it from the slow erosion that complexity brings. And eventually, if we keep exercising this muscle, we’ll start designing more elegant models ourselves.
Forward this to a fellow actor on your team.
Bonus points if you use DDD Command syntax.
Keep Exploring
Actor Fundamentals (akka.io)
Actors: a model of concurrent computation in distributed systems (archive.org)
The Actor Model (wikipedia)
A Feature Model of Programming Languages (sciencedirect)
The Actor Model Whiteboard Session with Carl Hewitt (youtube)
The Actor Model, Behind the Scenes with XState (youtube)
Why Did the Actor Model Not Take Off? (reddit)