Catalog
concept#Architecture#Software Engineering#Reliability

Actor Model

A model for concurrent and distributed systems that represents isolated, stateful actors which interact solely via asynchronous messages.

The Actor Model is a foundational computational model for concurrent and distributed systems.
Established
High

Classification

  • High
  • Technical
  • Architectural
  • Intermediate

Technical context

message brokers (Kafka, RabbitMQ) for persistence/forwardingpersistence backends for snapshots (e.g., Cassandra, PostgreSQL)monitoring tools for latency and restarts (Prometheus, Grafana)

Principles & goals

Isolation: actors encapsulate state and internal logic.Asynchronous communication: exchange occurs solely via messages.Fault tolerance via supervisors: failures are handled and contained locally.
Build
Enterprise, Domain, Team

Use cases & scenarios

Compromises

  • Unconsidered failure scenarios can lead to hidden restart loops.
  • Excessive messaging can cause performance bottlenecks and backpressure.
  • Incorrect partitioning of responsibility creates inconsistent state.
  • Limit actor state to the necessary minimum.
  • Use supervisors in a clearly structured and documented way.
  • Implement observability (metrics, tracing) for mailbox and restart rates.

I/O & resources

  • requirements for concurrency and fault tolerance
  • event or message sources
  • runtime environment with actor implementation (e.g., Akka, Erlang, Orleans)
  • isolated, stateful components
  • improved fault tolerance via supervisor strategies
  • scalable message processing pipelines

Description

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 supervisor hierarchies.

✔

  • Scalability via loose coupling and independent execution instances.
  • Improved failure containment via supervisor hierarchies.
  • Clear mental model for concurrent processes and state management.

✖

  • State management across many actors can become complex.
  • Distributed consistency and transactions are not automatically solved.
  • Debugging asynchronous message flows requires specialized tools.

  • mailbox latency

    Average time between message arrival and processing.

  • actor restart rate

    Number of restarts per actor per time unit.

  • throughput per actor type

    Processed messages per second for an actor type.

Erlang/OTP supervisors

Erlang implements actor-like processes with supervisor trees for failure containment.

Akka (JVM) actor system

Akka provides a scalable actor framework with typed actors and supervision strategies.

Orleans (Microsoft) virtual actors

Orleans uses the virtual actor model for simplified lifecycle management and scaling.

1

Design: define actor boundaries and message flows.

2

Prototype: implement and measure critical components as actors.

3

Harden: introduce supervisor structures and persistence/snapshot strategies.

⚠️ Technical debt & bottlenecks

  • insufficient snapshot and migration strategies for actor state
  • ad-hoc supervisor rules without tests and rollback plans
  • no standardized message formatting causing compatibility issues
mailbox backlogstate consistencyinter-actor communication
  • using actors as a substitute for missing transaction logic
  • persisting large state directly in actor memory instead of externalizing
  • misconfigured supervisors causing repeated restarts
  • underestimating latency in distributed messaging paths
  • ignoring backpressure strategies under high load
  • neglecting monitoring and alerting for restart rates
understanding of asynchronous programming and concurrencyknowledge of actor frameworks and their runtime behaviorexperience with distributed systems and fault-tolerance patterns
Concurrency and scalabilityFault tolerance and self-healingLoose coupling and modular state management
  • • No built-in distributed transactions; external coordination required.
  • • Dependence on runtime for mailbox and supervisor behavior.
  • • Latency and throughput are limited by messaging infrastructure.