Introduction: The Nightmare of Shared State

The Threading Problem

Imagine two bank tellers sharing a single ledger book. Teller A is in the middle of writing a deposit when Teller B grabs the book to record a withdrawal. The result is a corrupted entry — neither transaction is recorded correctly. This is exactly what happens when multiple threads share memory without coordination.

In traditional programming (Java, C++, Python), concurrency is handled using threads — independent execution paths that share the same memory space. This creates a class of bugs that are notoriously difficult to reproduce and fix:

• If Thread A writes to a variable while Thread B reads it simultaneously, you get a race condition — garbage data or partial writes.
• To prevent this, you use locks (also called Mutexes or Monitors). A lock forces threads to take turns: only the thread holding the lock can access the protected data.
• But locks introduce their own failure mode: deadlock. If Thread A holds Lock 1 and waits for Lock 2, while Thread B holds Lock 2 and waits for Lock 1, both threads freeze forever. The program hangs with no error message.

Thread A:  acquire(Lock1) → waiting for Lock2 → ❌ FROZEN
Thread B:  acquire(Lock2) → waiting for Lock1 → ❌ FROZEN

At small scale, careful engineering can manage this. At the scale of a distributed system with hundreds of services and thousands of threads, it becomes unmanageable. Every new lock is a potential deadlock. Every shared variable is a potential race condition.

The Actor Solution

The Actor Model was first formalized by Carl Hewitt at MIT in 1973 and popularized by the Erlang programming language in the 1980s (built by Ericsson for telecom systems that needed to run for years without downtime). Its core insight is radical: eliminate shared state entirely.

An Actor is the fundamental unit of computation in this model. Every actor has exactly three things:

1. Private state — data that belongs exclusively to this actor. No other actor can read or write it directly. Ever.
2. A mailbox — a queue where incoming messages wait to be processed.
3. A behavior — logic that runs when a message is received, which can read/modify private state and send messages to other actors.

Because only one message is processed at a time inside an actor, and because no external code can touch the actor's state, locks are never needed. There is nothing to lock. The actor itself is the serialization point.

The model scales naturally to distributed systems: actors on different machines communicate the same way as actors on the same machine — by sending messages. The network is just a longer mailbox.