Skip to content

CONCEPT Cited by 1 source

Actor model

Definition

The actor model is a concurrency + distributed-systems programming model in which:

  1. The unit of state + behavior is an actor — an addressable entity with a private internal state that no other actor can touch directly.
  2. Actors communicate exclusively by asynchronous message passing — one actor cannot read another's memory, invoke its methods synchronously, or share its CPU time.
  3. When an actor receives a message, it processes it to completion — serial, single-threaded execution — and may: modify its own state, send messages to other actors, spawn new actors.

The model originated with Carl Hewitt (1973, A Universal Modular Actor Formalism for Artificial Intelligence) and has been re-articulated in Erlang/OTP (1986), Scala/Akka (2009), Microsoft Orleans (2010), and the modern serverless / edge-compute era (Cloudflare Durable Objects, Azure Durable Entities).

Why the shape matters

The actor model gives — by construction — a set of invariants that are otherwise hard-earned in conventional shared-memory programming:

  • No races on actor-internal state, because only the actor processes messages addressed to it, one at a time.
  • Single source of truth per key — actor address = routing identity = owner of that state.
  • Location transparency — actors are addressable by name; the runtime picks the physical placement and can move them.
  • Isolation — an actor crash doesn't corrupt another actor.
  • Back-pressure via mailbox — slow consumers are visible.

These properties compose well with per-entity scaling: one actor per user, per file, per session, per device.

Addressability + embedded state

In the Cloudflare realisation (systems/cloudflare-durable-objects):

  • Each actor has a globally-unique identity (typically a user-chosen name hashed to a deterministic ID).
  • The runtime routes all messages for that identity to the same instance — single-writer by construction.
  • Each actor has its own embedded SQLite — state is persistent without needing an external database.
  • Idle actors hibernate and consume zero compute; they wake on message (HTTP, WebSocket, alarm, RPC).

"Each agent is an addressable entity with its own SQLite database. It consumes zero compute when hibernated. When something happens… the platform wakes the agent, loads its state, and hands it the event." (Source: Cloudflare Project Think.)

Why agents are the 2020s-era killer app for actors

See concepts/one-to-one-agent-instance for the load-bearing match. The summary: a traditional web request handler serves many users from one process and does not need addressability or embedded state; an AI agent instance serves exactly one user per session with substantial accumulated memory. That shape is what the actor model was designed for — it took 50 years for a workload to naturally fit it at internet scale.

The Project Think substrate's design explicitly invokes the actor model:

"The Agents SDK builds on Durable Objects to give every agent an identity, persistent state, and the ability to wake on message. This is the actor model: each agent is an addressable entity with its own SQLite database."

Typical workload fit

  • Per-user session state — chat histories, personal agents, collaborative documents.
  • Per-entity coordination — one actor per order, reservation, booking, ticket; serialises conflicting updates to that entity.
  • Stateful pipelines — one actor per topic / partition / shard with embedded accumulation state.
  • Real-time games — one actor per room / match.

Contrast with other programming models

  • Stateless web services (concepts/stateless-compute): no addressability, no per-instance state, any worker can handle any request. Cheapest to scale horizontally; worst fit for per-user memory.
  • Serverless functions (concepts/serverless-compute): scale-to-zero + per-request isolation, but no addressable identity and no embedded state. An actor is a serverless function plus identity plus state.
  • Task + actor model (concepts/task-and-actor-model): Ray's hybrid model — stateless tasks for fan-out compute + stateful actors for coordinators / caches / model-training loops. Actors are one half of that pair.

Implementation tensions

  • Single-writer is a feature and a constraint. Serialisation prevents races but is also a throughput ceiling — a hot actor is a bottleneck; sharding an actor is an application-level responsibility.
  • State migration — if the platform moves an actor, the state must move with it (hence embedded SQLite in Durable Objects rather than RAM-only). The embedded-store choice tightly couples durability to identity.
  • Cross-actor transactions are expensive — two-phase commit across actors is possible but not the actor model's strong suit. Design applications so any single invariant lives in one actor.

Lineage note

The actor model predates much of the current ecosystem by decades. Its recent renaissance (serverless + agents + edge) is implementation-economics catching up: hibernation + embedded SQLite + platform-managed restart make "one actor per session per user" economic in a way it wasn't when every actor needed an always-on process.

Seen in

Last updated · 200 distilled / 1,178 read