Actor Model

In most programming, objects call methods on each other directly. Object A calls B.doSomething(), and A waits until B finishes. This creates tight coupling, shared mutable state, and concurrency nightmares. When two threads call methods on the same object simultaneously, you get race conditions, deadlocks, and the kind of bugs that only manifest in production at 3 AM.

Carl Hewitt proposed the Actor Model in 1973 as a radical alternative: what if objects couldn't call each other's methods at all? What if the only way to communicate was by sending messages, like letters in the mail? You drop a message in Actor B's mailbox and continue with your life. B processes the message when it gets around to it. No shared state. No locks. No waiting.

This isn't just a theoretical model. Ericsson built Erlang around it, and Erlang runs the phone systems that handle billions of calls with 99.9999999% uptime (nine nines, about 31 milliseconds of downtime per year). WhatsApp handled 2 million concurrent connections per server using Erlang. Discord runs its infrastructure on Elixir (which runs on the Erlang VM). Akka brought the actor model to the JVM, and it powers systems at LinkedIn, PayPal, and Walmart.

The actor model solves concurrency by eliminating its root cause: shared mutable state. If actors never share state and only communicate via messages, there's nothing to lock, nothing to race on, and nothing to deadlock.

An actor is the fundamental unit of computation. When an actor receives a message, it can do exactly three things:

1. Create new actors, spawn child actors to delegate work.

2. Send messages, put a message in another actor's mailbox. The send is asynchronous, fire and forget.

3. Decide how to handle the next message, change its internal state, which affects how it processes the next message. This is the actor's "behavior."

That's it. Three axioms. Everything else follows from these.

Key properties:

• Location transparency, you send a message to an actor's address. You don't know (or care) if that actor is in the same process, on another machine, or in another data center. The runtime handles delivery. This makes distributed systems a natural extension of local computation.

• Mailbox processing, each actor has a mailbox (queue). Messages are processed one at a time, sequentially. This eliminates concurrency within a single actor, no need for locks or synchronization. Concurrency exists between actors, not within them.

• Supervision, when an actor fails, its supervisor decides what to do: restart it, stop it, escalate the failure, or resume it. This is Erlang's "let it crash" philosophy, don't try to handle every error defensively. Let actors crash and restart cleanly.

The full lifecycle of an actor from creation through crash and restart follows a state machine pattern that every actor framework implements: