TL;DR — Erlang’s actor model proves that isolated processes with immutable messages can scale to millions without locks; we’ll cover the core patterns, supervision strategies, and how modern runtimes like Elixir and the BEAM adapt these ideas for cloud-native workloads.
Erlang/OTP has powered some of the world’s most demanding telecom switches for over three decades, not because of raw speed, but because its actor-inspired runtime treats concurrency as a first-class contract. In an era where services must survive node failures, scale across cores, and avoid global locks, the principles behind Erlang’s processes, links, and supervisors are more relevant than ever. This post walks you through the actor model’s theoretical roots, the concrete patterns that make OTP production-ready, and how those ideas translate to modern runtimes and infrastructure.
The Actor Model Foundations in Erlang
At its core, the Erlang actor model diverges from the thread-based concurrency most systems inherit from Unix. An Erlang process is a lightweight abstraction—each consumes mere kilobytes of stack space, and the BEAM VM can schedule millions concurrently. Unlike OS threads, Erlang processes never share memory; communication occurs exclusively via asynchronous message passing through mailboxes.
The model rests on three axioms:
- Isolation: No shared state means no data races, and no locks are needed for internal process logic.
- Asynchrony: Messages are enqueued and processed on the process’s own schedule, enabling back-pressure and flow control naturally.
- Failure transparency: Processes can monitor each other and exit cleanly, triggering supervisor interventions without corrupting global state.
Joe Armstrong, Erlang’s creator, framed this as “let it crash”—a philosophy where failures are expected, contained, and recovered from automatically. This is not negligence; it’s a deliberate architecture for resilience.
-module(counter).
-export([increment/1, get/0]).
increment(Pid) ->
Pid ! {self(), increment},
ok.
get(Pid) ->
Pid ! {self(), get},
receive
{result, Count} -> Count
after 1000 ->
timeout
end.
The snippet above illustrates how a process receives a message, performs work, and replies—all without blocking a shared mutex. The receive block pattern is idiomatic Erlang for handling asynchronous replies with a safety net.
OTP’s Core Patterns: Supervision, Linking, and Isolation
The Open Telemetry Platform (OTP) builds on the actor model with a suite of abstractions that turn raw processes into reliable services. The most critical patterns are links, monitors, and supervision trees.
A link establishes a bidirectional death notification between two processes. When one exits abnormally, the other receives an exit signal and can react—typically by also exiting, which propagates failure upward. This “one-for-one” dynamic is the backbone of OTP’s fault containment.
A monitor is weaker: it observes another process and receives a one-way notification on exit, without forcing the monitor to terminate. Monitors are useful when you want to clean up resources without cascading failures.
A supervision tree arranges processes in a hierarchy, each supervised by a parent that defines a restart strategy (one_for_one, one_for_all, one_for_all, or rest_for_one). The BEAM ships with a generic supervisor behavior that handles the boilerplate of starting, monitoring, and restarting child processes according to policy.
-module(my_app_sup).
-behaviour(supervisor).
-export([start_link/0]).
start_link/0 ->
supervisor:start_link({local, ?MODULE}, ?MODULE, []).
init([]) ->
{ok, {{one_for_one, 5, 10}, [
{worker, {my_worker, start_link}, permanent, 5000, worker, [my_worker]}
]}}.
This minimal supervisor restarts a single worker up to five times within 10 seconds before giving up. The one_for_one strategy means only the failing child restarts—neighbors remain untouched.
Architecture: Fault-Tolerant Design with Supervision Trees
In production, the supervision tree is where Erlang’s actor model stops being a theoretical curiosity and becomes an operational asset. Consider a typical web gateway: the HTTP client process spawns a request-handling child, which may internally database-access, cache, and compose responses. If the database call throws an unexpected exception, the child exits, the supervisor restarts it, and the parent returns a graceful error to the caller—all without the outer system knowing a failure occurred.
This pattern scales across clusters. Erlang’s global module, pg2 (process group), and dets/mnesia distributions let supervision trees span nodes. A supervisor on node A can monitor a child on node B, and the runtime transparently routes exit signals across the network.
A real-world example is WhatsApp’s early infrastructure, which ran on a handful of Erlang nodes handling millions of concurrent connections. Each connection was a process, message passing handled protocol state, and supervisors ensured that a corrupted packet handler didn’t bring down the entire gateway. The system’s “five nines” availability stemmed from this isolation-first design.
% Example: Linking and monitoring in a supervisor context
init([]) ->
{ok, {{one_for_one, 0, 1}, [
{sup, {super_child, start_link, [normal]}, permanent, 5000, worker, [super_child]}
]}}.
The super_child might itself be a supervisor, nesting trees deeper. The BEAM guarantees that even deeply nested failures propagate only as far as the restart strategy permits.
Modern Runtimes: BEAM, Elixir, and the Evolution of Actor Ideas
While Erlang popularized the actor model on the BEAM VM, the concept has leached into general-purpose languages via libraries and runtime redesigns. Elixir, a functional language that compiles to BEAM, exposes the same primitives with a Ruby-friendly syntax and adds metaprogramming macros that make supervision trees almost declarative.
defmodule MyApp.Supervisor do
use Supervisor
def start do
Supervisor.start_link(__MODULE__, [], name: MyApp.Supervisor)
end
def init(_) do
Supervisor.init([worker(MyApp.Worker, [])], strategy: :one_for_one)
end
end
Elixir also introduces tasks and agents as higher-level abstractions. A Task wraps a concurrent computation with built-in result retrieval; an agent encapsulates a process holding mutable state behind message passing, giving you the safety of actors without managing process IDs manually.
Beyond Elixir, the actor model influences systems like Akka (JVM), Pykka (Python), and even Kafka’s consumer groups, which conceptually resemble partitioned actors processing streams. The common thread: treat concurrency as state isolation + message passing, and let the runtime handle scheduling and failure.
Interop and Integration: Actors in Distributed Systems
Pure in-memory actors are powerful, but modern systems rarely live in a single BEAM node. The actor model shines when integrated with external systems through controlled boundaries.
Message serialization: Erlang’s term format (Erlang term format, ETF) allows binary-safe serialization that the VM can deserialize without a garbage-collection pause. For cross-language interop, JSON or protobuf are common, but each adds latency and schema management.
External actors: Tools like erpc enable remote procedure calls between BEAM nodes, effectively extending the supervision tree across a cluster. Similarly, mnesia provides distributed tables that act like a shared-nothing database but retain the transactional semantics of individual processes.
Hybrid patterns: A common production pattern is the “actor per aggregate” in domain-driven design. An aggregate root is an actor that encapsulates business invariants, while external services interact via commands and events sent as messages. The actor validates, mutates its internal state, and publishes events—all without exposing its mailbox or process ID to the caller.
Consider a payment-processing system: an payment_actor receives authorize, capture, and refund messages. It validates card state, updates internal ledger, and emits PaymentAuthorized or PaymentFailed events. Downstream services subscribe to these events via a message broker (Kafka, RabbitMQ) and update read models. The actor remains the source of truth; the broker is merely a communication layer.
%% Simplified payment actor loop
loop(State) ->
receive
{authorize, CardNum, Amount} ->
% validate, charge, reply
Reply = charge_card(CardNum, Amount),
sender() ! {self(), Reply},
loop(State after_charge);
{capture, TxnId} ->
% capture logic
loop(State after_capture);
shutdown ->
ok
after 5000 ->
timeout
end,
loop(State).
The timeout clause is a defensive pattern: if no message arrives within 5 seconds, the process logs a timeout and either retries or escalates, depending on business logic.
Key Takeaways
- Isolation over locks: Erlang’s actor model eliminates data races by design—processes never share memory, and communication is explicitly via messages.
- Supervision trees are the fault-containment mechanism: By organizing processes in hierarchies with defined restart strategies, you isolate failures and recover automatically.
- The BEAM scales to millions of concurrent entities: Lightweight processes, not OS threads, are the unit of concurrency. This is why WhatsApp, Discord, and many telecom switches rely on Erlang.
- Modern runtimes preserve the core ideas: Elixir, LFE, and even ports of the model to other VMs bring actor-patterns to broader audiences without sacrificing the resilience foundations.
- Integration requires deliberate boundaries: When actors interact with external systems, serialization, remote procedure calls, and event streaming must respect the isolation principle—otherwise you reintroduce the race conditions the model avoids.