Loading content
The Actor Model is a foundational computational model for concurrent and distributed systems. It represents actors as isolated, stateful entities that communicate via asynchronous messages. It enables scalability, fault tolerance and loose coupling, but requires explicit design for state management and failure handling. Implementations use mailboxes and supe…
Use this profile to understand the building block briefly, place it in the model, and switch to the 360° assessment when needed.
Theoretical construct: explains a term, principle, or mental model.
What you need to understand to reason about a domain.
The Actor Model describes concurrent systems as a set of isolated actors with their own state. They react to messages, change only private state, and coordinate without shared memory.
The model was formulated in 1973 in work by Carl Hewitt, Peter Bishop, and Richard Steiger. It responded to the challenge of coordinating many independent computing units on machines with local memory and high parallelism, without lock-based synchronization or shared variables. Message passing makes interaction explicit and suits systems that need isolated processing and distributed control.
Think of an actor system as a row of sealed workspaces where only one unit acts at a time. Each workspace has its own mailbox and private state. Messages arrive asynchronously, are processed one by one, can change state, and may trigger new actors. Coordination emerges from passing messages along, not from reaching into another actor's data.
Actors affect one another only through messages; direct memory access is avoided.
Multiple actors can run independently and at the same time without contending over shared variables.
Each actor owns its state and keeps it shielded from other participants.
Messages are buffered and processed in sequence instead of being turned into direct calls.
Faults can be contained within one actor or a supervision tree when recovery is modeled deliberately.
The model is useful for distributed services, real-time workflows, and systems with many independent tasks or failures. It reduces lock contention and supports scaling, but it demands clear message contracts, idempotent handling, and explicit failure design; global consistency and synchronous coordination become more expensive.
Where this building block is located in the topic model.
No structure path available.
Explore how this building block connects to concepts, methods, technologies, and tools.
These sources establish the term and its professional meaning.
All direct connections of the current building block in a compact text view.
This classification shows where the building block typically matters, how demanding it is, and what kind of impact it has in the model.
The level within the organization (enterprise, domain, team) at which the AssetBlock is applied.