A message is an immutable data structure sent between actors. It requests processing or communicates an event; actors receive one message at a time and run behavior in response. Sending is asynchronous, so a sender can continue without waiting for a result. section 1.2 section 1.6.2
Messages replace direct method calls between actors. An actor exposes no mutable internal state, so other actors cannot alter a conversation’s stored messages or share a mutable list with it. Immutability prevents concurrent actors from changing the same message accidentally; when confirmation matters, the receiver sends an acknowledgment message back. section 1.6.2 section 1.5.4
Use messages to keep a system flexible as it grows:
- Send events when something interesting happens, allowing interested components to subscribe rather than forcing direct coordination. section 1.5.2
- Keep publishers running while event subscribers crash, restart, or receive events later. section 1.5.3
- Move communicating actors between servers without changing the message-oriented model. section 1.2 section 1.6
Chat events
A Conversation actor can publish an event after adding a message. A Mentions component can react to that event, while NotifyUser sends a UserMentioned message to a connected browser. Conversation does not need to know whether Mentions is available, and conversations can continue if it fails. section 1.5.2 section 1.5.3
Messages go to an ActorRef, wait in its mailbox, and are processed later by the actor one at a time in arrival order. section 1.7.2
Wallet commands
A wallet actor provides a minimal setting for sending messages: first, a deposit message only prints the deposited amount; later variants retain a total and can be deactivated or activated. Scheduled sending extends the same interaction with delay. section 2.0
