The Actor Model: Fast, Safe Software

Building systems that scale without the headache of locks.

ArchitectureConcurrencyDistributed SystemsActor Model

Learn how the Actor Model fixes concurrency issues by throwing away shared memory and using message-passing for resilient, fault-tolerant systems.

System Architecture

The Actor Model: A Better Way to Build Fast, Safe Software.

When computers got more chips instead of faster speeds, the old rules of programming broke. Here is how we fix it by throwing away "locks" and using "actors."

TOPIC: CONCURRENCY

ORIGIN: CARL HEWITT, 1973

DIFFICULTY: ADVANCED

The Problem with "Locks"

In older programming models, developers had to manually share memory data between different tasks. To stop tasks from changing the same data at the exact same time and ruining it, they used locks. Think of a lock like a bathroom key. Only the person holding the key can go inside. While this sounds safe, it causes massive headaches as a system grows.

Deadlocks

Two tasks are stuck forever because Task A is waiting for Task B's key, and Task B is waiting for Task A's key. Nobody moves.

Livelocks

Tasks are busy moving around and politely handing keys back and forth to avoid deadlocks, but they never actually get any real work done.

Starvation

One poor task never gets a turn because bigger, faster tasks keep grabbing the key before it can.

Real World Failure

MARS PATHFINDER MISSION

A famous example of lock failure happened on the Mars Pathfinder robot. This is called Priority Inversion.

A low-priority task (checking the weather) grabbed a lock. A high-priority task (communicating with Earth) needed that same lock, so it had to wait. Then, medium-priority tasks jumped in line and blocked the weather task from finishing.

The result? The high-priority radio was starved, the system crashed, and Earth lost contact with Mars.

The Solution: The Actor Model

In 1973, Carl Hewitt proposed a different way. He looked at physics: two physical objects cannot share the exact same space. So why should computer tasks share the same memory?

In the Actor Model, there is no shared memory. There are only "Actors."

THE 3 RULES (AXIOMS) OF AN ACTOR

Send Messages

An actor can send a message to another actor, as long as it knows the address. It drops the message in the mail and immediately goes back to work without waiting.

Create New Actors

If an actor has too much work, it can spawn new child actors to help out. A shopping cart actor might spawn a payment actor and a shipping actor.

Change Its Own Behavior

Instead of changing a shared variable, an actor changes its own rules for the next message. If a bank account actor gets a "$5 deposit" message, it decides that the next time it reads a message, it will act like an account with a larger balance.

Inside an Actor

To make this work in real life, frameworks break an actor down into three physical parts.

1. Mailbox

A line (queue) where incoming messages wait. The actor pulls them out one by one.

2. Behavior

The brain of the actor. The code that decides what to do with the current message.

3. Private State

The actor's own data. No one else can see or touch this data. Ever.

The Golden Rule of Thread Safety

Because the actor only processes one message at a time from its mailbox, the inside of the actor is completely safe. There is no race to change data, so you never have to write complex lock code again.

Fault Tolerance: "Let It Crash"

In old software, developers tried to catch every single error to stop the whole app from going down. The Actor Model does the opposite. It says: Let it crash.

Because actors do not share memory, if one actor hits a fatal error and dies, it does not poison the rest of the system.

Instead of trying to patch up broken data, a parent actor (the Supervisor) notices the child crashed and simply restarts it fresh. This is why telecom systems built on this model can run for years without ever being shut down.

SUPERVISION TREE

Supervisor

Worker

CRASH!

ACTION: RESTART CRASHED WORKER

How it Compares

Standard Async (Tasks)

Things like C# Tasks or JavaScript async/await.

Great for local, simple operations.
Breaks down when stretched across a network.
Hard to track errors in long chains.

The Actor Model

Things like Erlang, Akka, or Swift Distributed Actors.

Location transparent: Works the same locally or across the planet.
Self-healing with supervision trees.
Never needs locks. True thread-safety.

The Actor Model: Fast, Safe Software

Send Messages

Create New Actors

Change Its Own Behavior

Standard Async (Tasks)

The Actor Model

More in this collection

Memory Management

Reliability

Distributed Systems

Systems Design

Networking

Engineering

Architecture

Systems Engineering