Actors are independent units of computation that communicate only by message-passing. Each actor processes its mailbox sequentially — no shared state, no locks needed. The pattern originated in Erlang (1986) and powers WhatsApp, Discord, modern JVM systems via Akka.

Advertisement

The model

An actor is a mailbox + behavior + state. Receive a message → process it (mutating own state) → optionally send messages to other actors → loop. Because each actor processes its mailbox serially, no concurrency primitives needed inside the actor.

Supervision

Actors form a tree. Each parent supervises its children — if a child crashes, parent decides: restart, stop, escalate. This 'let it crash' philosophy makes systems self-healing. Failures are normal; recovery is structured.

Advertisement

Location transparency

An actor reference looks the same whether the actor is on this JVM or another machine. Send a message; the framework routes it. Enables transparent horizontal scaling.

Anti-patterns

Blocking inside an actor (DB call, sleep): blocks the whole mailbox. Use Futures or dedicated worker actors for IO. Holding too much state in one actor: becomes a hot spot. Split by entity ID. Cross-actor synchronous calls: introduces deadlock risk; prefer async.

Frameworks

Akka (Scala/Java) is the mature JVM choice. Akka.NET for C#. Erlang/Elixir for native actor language. Rust: Actix (web-focused) or Bastion. Picking depends on language; the model is the same.

One actor at a time per mailbox = no locks needed. Supervision = self-healing. Don't block inside an actor.