Book 3 — Advanced OTP & Application Design

GenServer and Supervisor cover the fundamentals; production systems need the rest of the toolbox. This book covers concurrency helpers (Task, Agent), process discovery (Registry), runtime-spawned children (DynamicSupervisor), shared fast storage (ETS), and how it all assembles into a bootable, shippable OTP application.

1. Task & Agent — concurrency without ceremony

Task wraps a process around one function call. It's your Promise/asyncio.gather equivalent — for when you want parallelism, not a long-lived server:

# async/await, BEAM style — each task is a real process on its own core
task = Task.async(fn -> expensive_computation() end)
other_work()
result = Task.await(task, 5000)

# Parallel map over a collection, max 10 at a time, streaming results:
urls
|> Task.async_stream(&fetch/1, max_concurrency: 10, timeout: 10_000)
|> Enum.to_list()

Agent is a GenServer reduced to "hold this value": Agent.get/2, Agent.update/2. Use it for simple shared state with zero protocol; graduate to GenServer the moment you need timers, handle_info, or real logic. (Many teams skip Agent entirely — it's fine.)

2. Registry — finding processes by name

Book 2 registered singletons with name: __MODULE__. But what about one process per entity — per user, per chat room, per game? You can't atom-name them (atoms are never garbage collected — dynamic atom creation is a leak). Enter Registry: a local, ETS-backed process directory supporting arbitrary terms as keys.

# 1. Start a registry (in your supervision tree):
{Registry, keys: :unique, name: MyApp.Registry}

# 2. Processes register via a "via tuple" in start_link:
def start_link(user_id) do
  name = {:via, Registry, {MyApp.Registry, {:session, user_id}}}
  GenServer.start_link(__MODULE__, user_id, name: name)
end

# 3. Callers address the process by key, no PID juggling:
GenServer.call({:via, Registry, {MyApp.Registry, {:session, 42}}}, :get_cart)

When the process dies, Registry automatically removes the entry (it monitors registrants). With keys: :duplicate, many processes can register under one key — a lightweight local pub/sub used to build things like Phoenix.PubSub.

3. DynamicSupervisor — children on demand

A plain Supervisor starts a fixed list of children at boot. A DynamicSupervisor starts empty and spawns children at runtime — one per incoming user, game, job:

# In the tree:
{DynamicSupervisor, name: MyApp.SessionSup, strategy: :one_for_one}

# At runtime, whenever a user shows up:
DynamicSupervisor.start_child(MyApp.SessionSup, {Session, user_id})

Combine the two patterns and you get the canonical Elixir architecture — process-per-entity:

# "Find or start the session for user 42, then call it"
def fetch_session(user_id) do
  case Registry.lookup(MyApp.Registry, {:session, user_id}) do
    [{pid, _}] -> {:ok, pid}
    [] -> DynamicSupervisor.start_child(MyApp.SessionSup, {Session, user_id})
  end
end

4. ETS — when a GenServer becomes the bottleneck

Everything so far routes reads through a single process, serially. For hot shared data (caches, counters, config) that's a bottleneck. ETS (Erlang Term Storage) is an in-memory table, owned by a process but readable/writable from any process concurrently, no message passing:

table = :ets.new(:my_cache, [:set, :public, :named_table, read_concurrency: true])
:ets.insert(:my_cache, {:user_42, %{name: "Ada"}})
[{_, user}] = :ets.lookup(:my_cache, :user_42)   # microseconds, from any process

The classic pattern: a GenServer owns the table and handles writes/invariants; readers hit ETS directly. Because the table can outlive GenServer crashes (with a heir or a separate owner), this also solves Book 2's "restart loses state" problem. Look up :ets.update_counter/3 for atomic increments (rate limiters love it).

Which tool? Interactive picker

5. Applications — how it all boots

An OTP application is the unit of packaging: your code + its supervision tree + its dependencies. Every Mix project has one; deps like Phoenix and Ecto are applications too, each booting its own tree. The entry point:

# mix.exs                                    # lib/my_app/application.ex
def application do                            defmodule MyApp.Application do
  [                                             use Application
    mod: {MyApp.Application, []},
    extra_applications: [:logger]               def start(_type, _args) do
  ]                                               children = [
end                                                 MyApp.Repo,
                                                    {Registry, keys: :unique, name: MyApp.Registry},
                                                    {DynamicSupervisor, name: MyApp.SessionSup},
                                                    MyAppWeb.Endpoint
                                                  ]
                                                  Supervisor.start_link(children,
                                                    strategy: :one_for_one, name: MyApp.Supervisor)
                                                end
                                              end

When you run iex -S mix or deploy, the VM starts each application, which starts its root supervisor, which starts its children in order. Your whole system's startup is a declarative tree, not a script. This is the file to read first in any unfamiliar Elixir codebase.

6. Releases — shipping it

mix release builds a self-contained directory: the BEAM VM, Erlang/Elixir, your compiled apps, and boot scripts. No Elixir installation needed on the target machine — copy, run bin/my_app start. Configuration at boot comes from config/runtime.exs (reads env vars — your 12-factor entry point). Inspect a live node with bin/my_app remote — a REPL inside production, one of the BEAM's killer debugging features.

Recap

Task for parallelism, Agent for trivial state, Registry to name dynamic processes, DynamicSupervisor to spawn them, ETS when a single mailbox is too slow, Application to declare the boot tree, releases to ship it. You now have the complete OTP vocabulary — everything from here on (Phoenix included) is these tools arranged nicely.