Asynchronous programming starts work without making the sender wait for completion. In an actor system, sending a message returns control to the sender immediately; the receiving actor processes messages one at a time when scheduled on a thread. This avoids hardwiring application components to particular threads and lets message processing remain local or move to another server without changing the communication model. section 1.2
The practical reason is to keep useful work moving when another component is slow, unavailable, or restarting. A synchronous supervisor that waits for every server response can block all subsequent calls when one component does not respond. An asynchronous model instead allows components to continue while responses are pending, which is essential when an application spreads across servers and network communication can fail. section 1.6.1
Actor-based asynchronous work relies on a small set of rules:
- Send immutable messages rather than directly calling another component or accessing its internal state. section 1.2 section 1.6.2
- Treat sending as fire-and-forget: the sender continues its own work after sending. section 1.6.2
- Request an acknowledgment message when delivery or receipt must be confirmed. section 1.6.2
- Use actor operations—creation, sending, selecting the next behavior, and supervision—as asynchronous operations. section 1.6.2
Chat components continue independently
A Conversation actor can send a message to a Mentions actor and immediately continue handling its own work rather than wait to see what happens. This decouples the two components: neither shares mutable conversation state, and the sender is not stalled by the receiver’s processing. If confirmation matters, the Mentions actor can later reply with an acknowledgment. section 1.6.2
Use the scaled-out chat layout to trace why waiting on every remote component can halt a supervisor when a server or network path fails. section 1.6.1
