Actor Model and Message Passing

In the actor model, an actor encapsulates state and processes messages.

12.1 Core idea

In the actor model, an actor encapsulates state and processes messages. Actors communicate through messages rather than directly sharing mutable state. An actor may update its private state, send messages, and create actors according to the model/runtime.

12.2 Conceptual actor example

The syntax is illustrative rather than a particular language. The actor serializes state transitions according to its runtime's rules, but message ordering and delivery guarantees depend on the implementation.

Actor message flow Text equivalent: the client sends messages to the actor's mailbox. The actor handles one message at a time, so its private count is never touched by two handlers at once; the reply to Get is just another message. Whether messages are delivered once, in order, or at all depends on the actor runtime.

actor Counter:
    state count = 0

    on Increment:
        count = count + 1

    on Get(replyTo):
        send replyTo, count

sequenceDiagram
  participant C as Client
  participant A as Counter actor
  C->>A: Increment
  C->>A: Increment
  C->>A: Get(replyTo = Client)
  Note over A: messages are processed one at a time from the mailbox
  A-->>C: 2

12.3 Mailboxes and supervision

Mailbox: queue of messages for an actor.

Supervisor: component that monitors child actors and decides how to respond to failure.

Backpressure: mechanism that prevents producers from overwhelming consumers.

Location transparency: code can interact with local or remote actors through similar abstractions, although network failure still exists.

12.4 Failure handling

A robust actor system defines:

Message schema and versioning Delivery guarantees and duplicate handling Retry and dead-letter policy State persistence/recovery where needed Mailbox limits and overload response

Authentication and authorization for remote messages

12.5 Actor model versus threads

Actors are an abstraction for managing state and communication. They may run on thread pools and do not mean that every actor receives a dedicated operating-system thread. The model can reduce shared-memory coordination but does not eliminate distributed-system failures.

Exercise

Design an actor-based order workflow with Order, Inventory, and Payment actors. Specify messages, timeout handling, duplicate events, and recovery behavior.

Quiz

? How does an actor protect its state?
+ Only the actor reads or writes it, processing one message at a time. :: No other code shares the mutable state.
- With a global lock around every actor. :: Actors avoid shared locks.
- By copying its state into every message. :: It sends values, but its own state stays private.
- By running on a dedicated OS thread. :: Actors usually share thread pools.

? What does a supervisor do?
+ Monitors child actors and decides how to respond to their failure (for example, restart). :: That is supervision.
- Delivers messages faster. :: It is about failure handling.
- Prevents all failures. :: It responds to failures; it does not prevent them.
- Stores the mailbox on disk. :: Persistence is a separate concern.

? Which must a robust actor system define? (select all that apply)
+ Delivery guarantees and duplicate handling :: Messages may be lost or repeated.
+ Mailbox limits and overload response :: Unbounded mailboxes exhaust memory.
+ Authentication for remote messages :: Remote actors are a network boundary.
- One OS thread per actor :: Not required and rarely used.