An actor is a lightweight, independent component that keeps its internal state private and reacts to messages. It is like a small programmable message queue: it does no work until a message arrives, then processes messages one at a time and may send messages to other actors. Applications are assembled from these message exchanges rather than direct method calls or shared mutable state. section 1.2 section 1.6.2
An actor works through four asynchronous operations:
- Create actors as lightweight application components. section 1.6.2
- Send messages in fire-and-forget style; request an acknowledgment message when confirmation matters. section 1.6.2
- Designate the next behavior, allowing behavior to represent changing state. section 1.6.2 section 2.0
- Supervise actors so a supervising component can decide whether failures warrant continuing, restarting, or stopping. section 1.6.2 section 1.5.4
Messages are addressed to an ActorRef, not to an actor’s internal state. The ActorRef places incoming messages in a mailbox, where they wait to be handled later in arrival order, one at a time. This separation lets an actor continue after sending a message instead of waiting for the recipient, helping components such as conversations, mentions, and notifications remain decoupled. section 1.7.2 section 1.6.2
Inspect the ActorRef–mailbox–actor path to see why callers send to an address and why processing is deferred and sequential. section 1.7.2
From a wallet to a chat service
A minimal wallet actor first prints each deposited amount, then evolves to retain a total and to deactivate or reactivate. The same pattern scales to conversation actors that hold conversation state, recover from events, and exchange messages with Mentions and notification components. A supervisor can observe those components and choose different responses when one or several stop working. section 2.0 section 1.5.4
Actor location can remain an implementation detail. An ActorRef can resolve to a local or remote actor, while application code continues to send messages in the same way. Changing reference lookup through configuration can move a solution from scaling up on available resources to scaling out across servers. Actors are not threads: their messages run on threads, but the actor-to-thread relationship is configurable. section 1.7.4 section 1.2
Actors also provide a boundary for fault handling. Re-creating plain objects and replacing direct dependencies can tangle recovery with processing logic. Actors instead communicate through references and can be created from Behaviors, suspended, and restarted as part of recovery. Their message-oriented design also supports tests that either isolate an actor with a stubbed ActorSystem or exercise multiple actors under indeterminate message order. section 5.1.1 section 4.0
