The Complete Actor Model Guide 2025: Erlang OTP, Akka, Orleans, Elixir — The Real Way to Handle Millions of Concurrent Connections

Introduction: The Miracle of 2 Million Connections

The WhatsApp Legend

In 2012, a WhatsApp engineer published a benchmark:

"2,000,000 TCP connections on a single server with FreeBSD + Erlang."

It became legend. C10K (10,000 concurrent connections) was considered hard at the time — but 2 million? How was this possible?

The answer was Erlang's Actor Model. Erlang, created in 1986 for Ericsson's telephone switches, was designed from the ground up for concurrency, distribution, and fault tolerance.

What is the Actor Model?

Proposed in 1973 by Carl Hewitt, the Actor Model is fundamentally different from traditional programming:

"Everything is an actor. An actor receives messages, sends messages, and creates new actors."

• No shared memory: All communication happens through messages.
• No locks: State lives inside actors only.
• Asynchronous: Messages are delivered asynchronously.
• Fault isolation: One actor's failure doesn't propagate to others.

From this simple model, remarkable systems are built.

What This Article Covers

1. The mathematical definition of the Actor Model.
2. Erlang/OTP: The original and the reference.
3. Akka: The JVM's actor implementation.
4. Elixir: Erlang's modern syntax.
5. Orleans: Microsoft's .NET Actor.
6. The Let it crash philosophy.
7. Supervision tree patterns.
8. Distributed actor systems.

Why This Knowledge Matters

• Concurrency: Handling millions of connections. Essential for modern backends.
• Fault tolerance: "Let it die" instead of "recover."
• Distributed systems: Same code for local and remote actors.
• Elixir: Modern frameworks like Phoenix LiveView.
• WhatsApp, Discord, Riot: The choice of major companies.

1. The Theory of the Actor Model

Three Fundamental Operations

Carl Hewitt's original definition:

1. Create: Create a new actor.
2. Send: Send a message to another actor.
3. Become: Determine behavior for the next message (state change).

That's all. These three operations can express any computation.

Components of an Actor

Each Actor has:

• Address (PID): Unique identifier.
• Mailbox: Queue of received messages.
• Behavior: A function defining how to handle messages.
• State: Internal state (inaccessible from outside).

    Actor A
    ┌─────────────┐
    │  Mailbox    │  ← msg3 ← msg2 ← msg1
    ├─────────────┤
    │  Behavior   │  (function: msg → action)
    ├─────────────┤
    │  State      │  (internal data)
    └─────────────┘

Message Processing Model

An actor processes one message at a time:

while True:
    msg = mailbox.pop()      # next message
    action = behavior(msg)    # handle with current behavior
    apply(action)             # state change, message sending, etc.

Key point: The inside of a single actor runs single-threaded. So the state inside an actor is free from concurrent modification concerns. No locks needed.

No Shared Memory

Communication between actors happens only via messages:

// wrong approach
actor_B.state.counter += 1  // illegal!

// correct approach
actor_B.send(IncrementMessage())

This constraint makes all concurrency problems disappear. No race conditions, no deadlocks, no locks. Instead, the complexity shifts to message passing.

Asynchronous Message Passing

Message sending is asynchronous:

actor_A.send(actor_B, msg)
// returns immediately. B will actually process it later.

This means:

• Sender is not blocked: The sender keeps doing other work.
• Backpressure: The mailbox can overflow (implementation-dependent).
• Ordering guarantees: Most implementations guarantee "messages from one A to one B arrive in order."
• Delivery guarantees: Local is at-most-once; remote depends on implementation.

Location Transparency

An actor's PID doesn't distinguish local from remote:

% same code
Pid ! Message

Whether Pid is on the same node or a different one, the code is identical. This enables transparent distribution. Erlang was the first to implement this principle.

Actor vs Thread

2. Erlang: The Power of the Original

History

• 1986: Built for Ericsson's telephone switches.
• 1998: Open-sourced.
• 1989: OTP (Open Telecom Platform) library.
• 2010s: Large-scale use at WhatsApp, Ericsson, Heroku, etc.

Language Philosophy

Erlang is an intentionally constrained language:

• Immutable: Variables are assigned only once.
• Pattern matching: The primary control flow.
• Functional: Minimal side effects.
• Dynamic typing: Runtime types.
• Single assignment: Prolog influence.

These constraints make concurrency safe.

Lightweight Processes

Erlang's actors are called "processes," but they aren't OS processes — they're scheduling units inside the VM:

• Size: Starts at roughly 300 bytes.
• Spawn cost: Under 1 μs.
• Context switch: Faster than OS threads.
• Concurrent process count: Millions are possible.

% Spawn 1 million processes
lists:foreach(
  fun(_) -> spawn(fun() -> loop() end) end,
  lists:seq(1, 1000000)
).
% Completes in seconds.

Impossible with OS threads. Erlang's lightness is the secret.

Send and Receive

% Spawn an actor (process)
Pid = spawn(fun() -> counter(0) end).

% Send a message
Pid ! {increment, 5}.
Pid ! {get, self()}.

% Receive messages
counter(N) ->
    receive
        {increment, Delta} ->
            counter(N + Delta);
        {get, From} ->
            From ! {count, N},
            counter(N);
        stop ->
            ok
    end.

! is send, receive is blocking message receive, and self() is your own PID.

Pattern Matching in Receive

receive scans the mailbox and retrieves the first message matching a pattern:

receive
    {urgent, Msg} -> handle_urgent(Msg);
    {normal, Msg} -> handle_normal(Msg)
after
    5000 -> timeout()
end.

• Selective matching (pick out specific messages to handle).
• Timeout support.
• Only matches — does not reorder the mailbox.

The Selective Receive Trap

Erlang scans the mailbox from the front. Unmatched messages remain in the pending queue:

receive
    {critical, X} -> ...
end.

If there's no {critical, _} in the mailbox, it waits forever, and other messages pile up, causing a memory explosion. This is Erlang's famous pitfall. Fix: always include a catch-all or an after timeout.

Erlang/OTP

OTP (Open Telecom Platform) is Erlang's standard library plus a collection of design patterns:

• gen_server: Generic server behavior.
• gen_statem: State machines.
• gen_event: Event handlers.
• supervisor: Supervision trees.
• application: Application structure.

OTP is the reusable design patterns of the actor model. When you build something in Erlang, you almost always build it on top of OTP.

gen_server Example

-module(counter).
-behaviour(gen_server).

-export([start_link/0, increment/1, get/0]).
-export([init/1, handle_call/3, handle_cast/2]).

start_link() -> gen_server:start_link({local, ?MODULE}, ?MODULE, 0, []).

increment(N) -> gen_server:cast(?MODULE, {increment, N}).
get() -> gen_server:call(?MODULE, get).

init(State) -> {ok, State}.

handle_cast({increment, N}, State) -> {noreply, State + N}.
handle_call(get, _From, State) -> {reply, State, State}.

Structured, familiar pattern. Easy to write and maintain.

3. Let It Crash: A Revolutionary Philosophy

Traditional Error Handling

In most languages:

try:
    result = risky_operation()
except Exception as e:
    log_error(e)
    # try to recover, or return failure
    return None

• Predict every possible error.
• Defensive programming.
• Problem: Unexpected errors still crash things.

Erlang's Approach

"Let it crash."

• Don't try to anticipate errors.
• If an actor fails, just let it die.
• The supervisor restarts it.

Your code focuses on the happy path, and failure is managed externally (by the supervisor).

Why Does This Work?

Traditional assumption: "Errors are exceptional." Erlang's assumption: "Errors are normal."

Networks disconnect, disks fill up, memory runs out. This is an everyday reality to be expected. But trying to handle every error case makes code complex.

Erlang's solution: restart on failure. After restart, you start from a clean state. This resolves most problems ("have you tried turning it off and on again?").

Supervision Tree

A Supervisor is a special actor that watches its child actors:

        Main Supervisor
       /      |       \
    Worker   Worker   Sub-Supervisor
                      /     |      \
                   Worker  Worker  Worker

Each supervisor has a restart strategy:

• one_for_one: Restart only the failed child.
• one_for_all: If one fails, restart all children.
• rest_for_one: Restart the failed child and all children after it.
• simple_one_for_one: Dynamically spawned children.

Restart Limits

"Infinite restart" is dangerous (wastes CPU if the same error repeats). Supervisors have restart limits:

• max_restarts: Max restarts per time window.
• max_seconds: Measurement period.

If exceeded, the supervisor itself dies, propagating to the parent supervisor. This is the hierarchical propagation of errors.

Example: WhatsApp Structure

Application Supervisor
├── Cluster Supervisor
│   ├── Node Manager
│   └── Distribution Manager
├── Connection Supervisor
│   ├── Connection 1
│   ├── Connection 2
│   └── ... (millions)
├── Message Supervisor
│   ├── Message Router
│   └── Storage Manager
└── Monitoring Supervisor
    ├── Metrics Collector
    └── Health Checker

Failures are isolated at each level. An error in one connection doesn't affect another. Trouble in one subsystem doesn't bring down the whole.

Lesson: Software That Accepts Failure

Let it crash is a paradigm shift in software design:

• Traditional: "My code must be perfect."
• Erlang: "My code will fail. The system keeps running anyway."

This fits the nature of distributed systems. In distributed systems, nothing is 100% trustworthy. Networks, hardware, software — all fail from time to time. Accept it, and design for it.

4. Akka: Actors on the JVM

Motivation

Started in 2009 by Jonas Bonér, who wanted to bring Erlang-style actors to the JVM, integrated with Scala.

In 2012, Typesafe (now Lightbend) began commercial support. Akka became synonymous with actors in the Java/Scala ecosystem.

Akka vs Erlang Differences

Language differences:

• Erlang: Dynamically typed, immutable, functional.
• Akka: Uses the JVM language's type system as-is.

Actor weight:

• Erlang: 200-300 bytes per process, perfect isolation.
• Akka: A few KB per Akka actor, JVM thread pool based.

Selective receive:

• Erlang: Native support.
• Akka: Can be approximated with Stash.

Culture:

• Erlang: "The language is the philosophy." The entire language is actor-centric.
• Akka: "A library." Can be mixed with JVM code.

Basic Akka Example (Scala)

import akka.actor.{Actor, ActorSystem, Props}

class Counter extends Actor {
  var count = 0

  def receive = {
    case Increment(n) => count += n
    case Get => sender() ! count
  }
}

val system = ActorSystem("MySystem")
val counter = system.actorOf(Props[Counter], "counter")

counter ! Increment(5)
counter ! Get  // response goes to sender

• Props: Actor creation config.
• receive: Message handler function.
• sender(): Ref of the current message's sender.

Typed Actor (Akka 2.6+)

Early Akka had Any-typed messages (Erlang style), giving up type safety. From Akka 2.6, Typed actors are the default:

sealed trait CounterMessage
case class Increment(n: Int) extends CounterMessage
case class Get(replyTo: ActorRef[Int]) extends CounterMessage

val counterBehavior: Behavior[CounterMessage] = Behaviors.setup { context =>
  var count = 0
  Behaviors.receiveMessage {
    case Increment(n) =>
      count += n
      Behaviors.same
    case Get(replyTo) =>
      replyTo ! count
      Behaviors.same
  }
}

Compile-time message type checking. Leveraging the JVM's strengths.

Akka Cluster

Akka Cluster ties multiple nodes into a single actor system:

• Gossip protocol: Node membership.
• Distributed actors: Used like local ones.
• Cluster Sharding: Automatic state distribution.
• Cluster Singleton: A single actor across the cluster.
• Distributed Data: CRDT-based shared state.

Cluster Sharding example:

val shardRegion = ClusterSharding(system).start(
  typeName = "User",
  entityProps = Props[UserActor],
  settings = ClusterShardingSettings(system),
  extractEntityId = extractEntityId,
  extractShardId = extractShardId
)

// Send a message with userId=42
shardRegion ! Envelope(42, SomeMessage)
// Automatically routes to whichever node holds the actor with ID 42

This automatically distributes millions of actors across dozens of nodes. Rebalances when nodes are added or removed.

Akka Persistence

Built-in Event Sourcing. Actor state changes are stored as an event log:

val behavior: Behavior[Command] = EventSourcedBehavior[Command, Event, State](
  persistenceId = PersistenceId("counter", "1"),
  emptyState = State(0),
  commandHandler = (state, cmd) => cmd match {
    case Increment(n) => Effect.persist(Incremented(n))
  },
  eventHandler = (state, evt) => evt match {
    case Incremented(n) => state.copy(count = state.count + n)
  }
)

When the actor restarts, the event log is replayed to recover state. Powerful for failure recovery in distributed systems.

Akka Pitfalls

1. "Child creation via Props": More complex than Erlang.
2. Legacy untyped actors: Many tutorials are still outdated.
3. JVM tuning: GC, heap, thread pool.
4. License change: Switched to BSL (Business Source License) in 2022. Large-scale commercial use is paid.

After the licensing issue, Pekko (Apache fork) emerged. 100% Akka-compatible. Open source.

5. Elixir: The Modern Face of Erlang

Birth

• 2012: Started by Ruby developer José Valim.
• Runs on the Erlang VM (BEAM).
• Ruby/Python-style syntax + Erlang's power.

Why Elixir?

Erlang is powerful but has alien syntax (Prolog influence). Many developers hit the barrier to entry. Elixir offers:

• Familiar syntax: Friendly to Ruby/Python users.
• Modern tooling: Mix (build), ExUnit (test), Hex (package manager).
• 100% Erlang compatible: All OTP, all libraries usable.
• Metaprogramming: Macros to build DSLs.

Example: Counter

defmodule Counter do
  use GenServer

  # Client API
  def start_link(initial \\ 0) do
    GenServer.start_link(__MODULE__, initial, name: __MODULE__)
  end

  def increment(n) do
    GenServer.cast(__MODULE__, {:increment, n})
  end

  def get do
    GenServer.call(__MODULE__, :get)
  end

  # Server callbacks
  def init(initial), do: {:ok, initial}

  def handle_cast({:increment, n}, state) do
    {:noreply, state + n}
  end

  def handle_call(:get, _from, state) do
    {:reply, state, state}
  end
end

Same structure as Erlang's gen_server, but much easier to read.

Phoenix and LiveView

Elixir's killer app: Phoenix framework. Rails-level web development productivity + Erlang's concurrency.

Phoenix LiveView: Server rendering plus real-time updates without JavaScript. Internally implemented with WebSockets and actors.

Performance: A single Phoenix server can handle millions of concurrent connections (WhatsApp-level).

Discord's Usage

Discord uses Elixir + Erlang at scale:

• Message routing: Elixir clusters.
• Concurrent voice chat: Millions of connections.
• 5 million+ concurrent users: Disclosed in a 2019 blog post.

This answers "Isn't Erlang a dead language?" Discord, WhatsApp, Riot (League of Legends chat), and other services with millions of users run on BEAM.

6. Orleans: Microsoft's Virtual Actors

History

• 2010: Started at Microsoft Research.
• Project Orleans goal: "Cloud-scale .NET actors."
• Halo 4+: Player matchmaking, stats, leaderboards.

Virtual Actors

Orleans' innovation: the virtual actor. The runtime manages actor lifecycles automatically:

Traditional actor:

• Developer explicitly creates/destroys.
• PID management required.

Virtual actor:

• Actor is assumed to always exist.
• Auto-activates when receiving a message.
• Auto-deactivates when idle.
• Auto-restored when restarting.

public interface ICounterGrain : IGrainWithIntegerKey
{
    Task Increment(int n);
    Task<int> Get();
}

public class CounterGrain : Grain, ICounterGrain
{
    private int count = 0;

    public Task Increment(int n)
    {
        count += n;
        return Task.CompletedTask;
    }

    public Task<int> Get() => Task.FromResult(count);
}

Usage:

var counter = grainFactory.GetGrain<ICounterGrain>(42);
await counter.Increment(5);
int value = await counter.Get();

When the counter grain with ID 42 is called for the first time, it's auto-created; after prolonged idleness, it's auto-deactivated. Developers don't worry about lifecycle.

Advantages

• Simplicity: No create/destroy code.
• Automatic failover: On node failure, recreated on another node.
• State persistence: Grain state is auto-saved via storage providers.
• .NET native: Leverages C# type system.

Disadvantages

• Runtime overhead: The cost of automation.
• Error model: A different approach from let it crash.
• Learning curve: The virtual actor concept feels unfamiliar at first.

Where It's Used

• Halo series game services.
• Parts of Azure internals.
• Financial trading (FIS and other partners).
• IoT: A grain per device.

The Only .NET Actor System?

Orleans is the most famous actor framework in the .NET ecosystem, but not the only one. There's also Akka.NET (Akka's .NET port), Proto.Actor, etc. However, Microsoft's official backing plus Azure integration makes Orleans the mainstream choice.

7. Other Actor Systems

Dapr Actors

Microsoft's Dapr (Distributed Application Runtime) is a sidecar-based distributed runtime. Dapr Actors are language-neutral virtual actors:

# Python
from dapr.actor import Actor

class CounterActor(Actor):
    async def increment(self, n):
        state = await self._state_manager.get_state("count")
        await self._state_manager.set_state("count", state + n)

HTTP/gRPC based, so any language can use it. Kubernetes friendly.

Akka.NET

Akka's .NET port. Used from F#/C#. An extension of the Akka philosophy, along with Pekko.

Pykka

A simple actor library for Python. Thread based.

Ray

Python's distributed computing framework. Includes an actor abstraction:

import ray

@ray.remote
class Counter:
    def __init__(self):
        self.count = 0

    def increment(self, n):
        self.count += n

    def get(self):
        return self.count

counter = Counter.remote()
counter.increment.remote(5)
count = ray.get(counter.get.remote())

Popular for ML workloads. Integrates with Ray Tune, Ray Serve, etc.

CAF (C++ Actor Framework)

High-performance actor framework for C++. Used in game engines and HFT.

8. The Secret of Millions of Concurrent Connections

Erlang's Secret

Why can Erlang handle millions of concurrent connections?

1. Lightweight processes:

• Start size ~300 bytes.
• Spawn cost ~1 μs.
• 1000x lighter than a JVM thread.

2. Preemptive scheduling:

• BEAM VM's preemptive scheduling.
• "Reduction" count after function calls.
• Forcibly preempted if a process holds the CPU for "too long."

3. Independent heap:

• Each process has its own heap.
• Per-process GC: GCing one process doesn't affect others.
• No "stop the world."

4. Share-nothing:

• No shared memory, so no lock contention.
• Messages are copied when sent (not local pointers).

5. Simple scheduler:

• One scheduler thread per CPU.
• Each thread has its own run queue.
• Work stealing balances the load.

Benchmark

Erlang's The Road to 2 Million Websocket Connections in Phoenix (2015 blog):

• Test: Phoenix Channels with WebSocket.
• Goal: 2 million connections.
• Result: Achieved on a single server.
• Memory: ~40 GB (20 KB per connection).
• CPU: Almost idle.

This is on a single server. Very hard with Node.js or Java.

Comparison: Go goroutines

Go's goroutines are famous for lightweight concurrency:

• Size: Starts at 2 KB (grows dynamically).
• Count: Millions possible.
• Performance: Similar to Erlang or slightly better.

But Go is not an actor model. Shared memory + channels. Error handling is also traditional (recover/defer).

Erlang's strength is its fault tolerance patterns and distribution transparency. In raw performance, it's roughly even with Go.

Practical Design: State Management

With millions of actors, state management matters:

1. In-memory: Each actor holds its own state. Fastest.
2. Persistent: Event sourcing stores an event log.
3. Distributed: CRDTs or a separate DB.

WhatsApp mainly used in-memory. Message routing is nearly stateless, so it's feasible. For more complex state, combine with Cassandra/DB.

9. Practical Patterns

Pattern 1: Request-Reply

The most basic pattern:

# synchronous call
reply = GenServer.call(server, :request)

# asynchronous cast (no reply)
GenServer.cast(server, :fire_and_forget)

call has an internal timeout (default 5 seconds). No reply → exception.

Pattern 2: Pub-Sub

# Subscriber
Phoenix.PubSub.subscribe(MyApp.PubSub, "chat:lobby")

# Publisher
Phoenix.PubSub.broadcast(MyApp.PubSub, "chat:lobby", {:new_message, msg})

# Subscriber receives
def handle_info({:new_message, msg}, state), do: ...

Naturally implemented in actor systems.

Pattern 3: Worker Pool

Distribute work across multiple worker actors:

# using poolboy
{:ok, pool_pid} = :poolboy.start_link(
  [worker_module: MyWorker, size: 10],
  init_args
)

worker = :poolboy.checkout(pool_pid)
result = MyWorker.process(worker, task)
:poolboy.checkin(pool_pid, worker)

Pattern 4: State Machine

State machines with gen_statem:

defmodule TrafficLight do
  use GenStateMachine

  def init(_), do: {:ok, :red, %{}}

  def handle_event(:state_timeout, :tick, :red, data) do
    {:next_state, :green, data, [{:state_timeout, 3000, :tick}]}
  end

  def handle_event(:state_timeout, :tick, :green, data) do
    {:next_state, :yellow, data, [{:state_timeout, 1000, :tick}]}
  end

  def handle_event(:state_timeout, :tick, :yellow, data) do
    {:next_state, :red, data, [{:state_timeout, 3000, :tick}]}
  end
end

State-based logic is explicit.

Pattern 5: Circuit Breaker

Easy to implement as an actor:

defmodule CircuitBreaker do
  use GenServer

  def call(name, func) do
    case GenServer.call(name, :state) do
      :closed -> try_call(name, func)
      :open -> {:error, :circuit_open}
      :half_open -> try_call(name, func)
    end
  end

  # ... handle failures and state transitions
end

10. Limitations and Pitfalls

Pitfall 1: Actors Aren't a Silver Bullet

Bad for compute-intensive work:

• Message passing overhead.
• A single actor is single-threaded.
• Doesn't fit parallel hardware like GPUs.

Fix: Do computation in other languages/systems, use actors for coordination.

Pitfall 2: Mailbox Explosion

Fast producer + slow consumer:

Producer: sends 1M messages/sec
Consumer: processes 10K messages/sec
→ 990K per second pile up in the mailbox
→ memory explosion, OOM

Fix:

• Backpressure: Consumer signals "slow down."
• Sampling: Drop when overflowing.
• Bounded mailbox: Configurable in Akka. Erlang is unbounded by default.
• Flow control: GenStage, Broadway (Elixir).

Pitfall 3: Selective Receive Performance

Erlang's selective receive scans the mailbox:

receive
    {specific, Msg} -> handle(Msg)
end

If the mailbox holds 100K messages and the wanted pattern is near the back, you scan 100K entries. Slow.

Fix:

• Process all messages in order without selective receive.
• spawn a new actor to branch specific messages.

Pitfall 4: Message Ordering in Distributed Environments

Locally, "A → B message ordering" is guaranteed. In distributed settings:

• Messages go over the network.
• Retries and reorderings happen.
• Eventual consistency.

Fix:

• Implement causal ordering explicitly if needed.
• Idempotent design.
• Event sourcing.

Pitfall 5: The Temptation of Global State

Against the actor philosophy, but sometimes for convenience:

# :ets tables can be shared outside processes
:ets.new(:shared, [:public, :named_table])

Such shared state is convenient but introduces lock contention and debugging pain. Use only when truly necessary.

Pitfall 6: Remote Call Timeouts

GenServer.call(remote_pid, :get, 5000)

5-second timeout. If the timeout is due to a network issue:

• You don't know whether it actually completed.
• For at-least-once, you need retries.
• But retries enable duplicates.

Fix: Idempotent design. Unique request IDs.

11. Actor Model vs Other Concurrency Models

vs Thread + Lock

• Thread: Shared memory, locks, complex.
• Actor: Messages, no locks, simple.

Actors are safer and simpler in most cases. But for compute-intensive work, threads are still faster.

vs CSP (Go channels)

CSP (Communicating Sequential Processes): Go's goroutines + channels. Similar to actors, but:

• Actor: Messages go to an actor's mailbox.
• CSP: Messages go to a channel (not tied to an actor).

Go's channels are more flexible but lack actors' "ownership" model, which can complicate reasoning.

vs Reactive Streams

Reactive Streams (RxJS, Reactor): Async data streams + backpressure.

Actors are "entity"-centric, Reactive Streams are "data flow"-centric. They complement each other and are often combined in practice.

vs Software Transactional Memory (STM)

STM (Clojure, Haskell): Memory accesses as transactions.

Actors don't need STM (no shared memory). Both are alternatives to lock-based concurrency, but with different approaches.

vs Event-driven (Node.js)

Node.js is a single-threaded event loop. One thing at a time.

Actors allow many actors to run in parallel. Each actor is sequential internally.

Node is simple and easy to understand but limited in CPU utilization. Actors add complexity but use multi-core freely.

12. Learning and Practice

Where to Start

Recommend Elixir + Phoenix:

1. Familiar Ruby/Python-like syntax.
2. Immediate access to all of Erlang OTP's power.
3. Phoenix for real projects.
4. "Programming Elixir" (Dave Thomas) book.
5. Phoenix LiveView for real-time web.

Erlang recommendation:

1. "Learn You Some Erlang" (free online).
2. "Programming Erlang" (Joe Armstrong).
3. OTP fundamentals without worrying about outdated tutorials.

Akka recommendation:

1. Natural choice on the JVM.
2. But mind the licensing issue (consider Pekko).
3. "Reactive Messaging Patterns with Akka" (rich material).

Orleans recommendation:

1. .NET environments.
2. Official Microsoft support.
3. Azure integration.

Practical Project Ideas

• Chat application: WebSocket + actors. Phoenix LiveView works well.
• Game server: An actor per player.
• Stock ticker: An actor per symbol.
• IoT device manager: An actor per device.
• Task scheduler: Worker pools.
• Metrics collector: Collect from many sources, aggregate.

Start small and feel the power of actors. You'll see how much simpler and safer it is than the shared-memory approach.

Real-World Cases

• WhatsApp: 2M+ connections per server.
• Discord: 5M+ concurrent users.
• Riot Games: League of Legends chat.
• Heroku: Routing layer.
• Klarna: Financial trading.
• Pinterest: Notification system.
• Bleacher Report: Real-time feeds.

All use Erlang or Elixir. Not a "niche language."

Review Quiz

behavior_0 = on increment, become behavior_1
behavior_1 = on increment, become behavior_2
...
behavior_N = on get, reply N to sender

try:
    result = db.query(...)
except ConnectionError:
    retry(3)
except Timeout:
    return cached_value()
except DataCorruption:
    log_and_skip()
except UnknownError:  # what if unexpected?
    raise  # process dies

handle_request(Req) ->
    Result = do_work(Req),  % no error checks
    reply(Result).

        Application
             │
      Main Supervisor
      /    |    \
   Child Child Sub-Supervisor
                 /    |    \
              Child Child Child

[A, B, C] and B fails
→ restart only B
→ [A, B', C]

[A, B, C] and B fails
→ restart all
→ [A', B', C']

[A, B, C, D] and B fails
→ restart B, C, D
→ [A, B', C', D']

{intensity, 10},  % max 10 restarts per period
{period, 60}     % within 60 seconds

ChatApp Supervisor
├── AuthService Supervisor
│   ├── User1 Session
│   ├── User2 Session
│   └── UserN Session       ← one session failure doesn't affect others
├── MessageRouter Supervisor
│   ├── RoomA Router        ← RoomA failure = affects RoomA only
│   ├── RoomB Router
│   └── RoomC Router
└── Storage Supervisor
    ├── Primary DB
    ├── Replica DB
    └── Cache

Actor ! Message  % to a specific actor

ch <- message  // through a channel

response = GenServer.call(user_server, :get_profile)

results := make(chan Result, 10)
for _, job := range jobs {
    go func(j Job) {
        results <- process(j)
    }(job)
}

Closing: Messages Are Everything

Core Summary

1. Actor model: Create, Send, Become — three operations.
2. No sharing: Communicate only through messages. No locks.
3. Erlang/OTP: The original. Millions of lightweight processes.
4. Let it crash: Accept failure and restart.
5. Supervision tree: Hierarchical fault tolerance.
6. Akka: Actors on the JVM. Led by Lightbend.
7. Elixir: The modern face of Erlang. Phoenix + LiveView.
8. Orleans: .NET's virtual actors.
9. Location transparency: Same code for local and remote.

When to Choose the Actor Model

Choose when:

• Thousands to millions of concurrent connections.
• Distributed systems.
• Fault tolerance matters.
• Entity-based domains (user, game player, IoT device).
• Stateful services.

Avoid when:

• Simple CRUD APIs.
• Compute-intensive tasks.
• Small systems.
• No team experience.

Final Lesson

Erlang started in 1986 and has evolved for nearly 40 years. Countless concurrency models have come and gone in that time. Erlang is still in active use.

Why? Joe Armstrong (Erlang co-creator, passed in 2019) said:

"If your system must handle 100,000 connections, you may be using the wrong language."

WhatsApp was acquired by Facebook in 2014 for $19 billion. Just 55 engineers served 450 million users. Erlang's power made that ratio possible.

The actor model is a paradigm shift. From "how do we synchronize shared memory" to "how do we collaborate through messages." It's a hard transition, but once accepted, many problems become simple.

Next time questions like "how do we handle many concurrent users?" or "how do we build reliable distributed systems?" come up, remember the actor model. This 1973 idea is still among the best answers.

References

• Erlang/OTP Official Documentation
• Learn You Some Erlang for Great Good! - Free online
• Programming Erlang (Joe Armstrong)
• Programming Elixir (Dave Thomas)
• Designing for Scalability with Erlang/OTP - Francesco Cesarini
• Akka Documentation
• Reactive Messaging Patterns with Akka
• Orleans Documentation
• Phoenix Framework
• Phoenix LiveView
• The Road to 2 Million Websocket Connections in Phoenix
• How Discord Scaled Elixir to 5M Concurrent Users
• Hewitt: Actor Model of Computation (1973 original)
• Joe Armstrong: Why Erlang Is Safe