Book 6 — Capstone: Build a Real-Time System

Everything converges here. You'll build Buzzword Bingo — a multiplayer real-time game — from a blank page: a pure functional core, a supervised OTP engine (one process per game room), and a LiveView UI where every player sees every move instantly. The notebook contains the full working build; this book is the architectural walkthrough and your map for doing it solo.

1. The spec

Players join a named room and get a 4×4 card of buzzwords. Any player can mark a square when the buzzword is uttered in their meeting. First player to complete a row, column, or diagonal wins — every connected player sees the win the moment it happens. Rooms are independent: a crash in one must never touch another. Idle rooms should clean themselves up.

Generic shape: many independent stateful entities + multiple concurrent users per entity + real-time fan-out. Swap "game room" for document, auction, shopping cart, chat channel, IoT device, or support ticket and the architecture is identical — this is the shape of most real-time systems.

2. Design first: the layer cake

The single most useful Elixir design discipline (from Designing Elixir Systems with OTP): do the work in pure functions; add processes only for runtime concerns (state over time, concurrency, failure isolation). Three layers:

3. The engine (Books 1–3 applied)

Core: a Game struct + pure transitions. Every function takes a game, returns a game (or an error tuple):

defmodule Game do
  defstruct [:squares, :marks, :winner, players: []]

  def new(words), do: ...                       # build the 4×4 card
  def mark(game, player, index), do: ...        # returns {:ok, game} | {:error, :already_won}
  def winner?(game), do: ...                    # rows/cols/diags check — pure
end

Runtime: the process-per-entity pattern, verbatim from Book 3:

defmodule GameServer do
  use GenServer, restart: :transient          # don't restart normal exits (idle shutdown)

  def start_link(room), do: GenServer.start_link(__MODULE__, room, name: via(room))
  defp via(room), do: {:via, Registry, {GameRegistry, room}}

  def handle_call({:mark, player, i}, _from, %{game: game} = state) do
    case Game.mark(game, player, i) do
      {:ok, game} ->
        broadcast(state.room, {:game_updated, game})   # PubSub → every player's LiveView
        {:reply, :ok, %{state | game: game}, @idle_timeout}
      {:error, _} = err -> {:reply, err, state, @idle_timeout}
    end
  end

  def handle_info(:timeout, state), do: {:stop, :normal, state}   # idle room exits cleanly
end

Design decisions worth noticing: call (not cast) for marks — the player should know their move landed, and it back-pressures spam-clicking. The GenServer timeout (the extra element in reply tuples) gives idle cleanup for free. restart: :transient means crashes restart the room, but idle exits don't resurrect it. Broadcasts happen in the server, not the UI — the engine is the single writer, so every observer sees identical state.

4. The UI (Books 4–5 applied)

The LiveView is deliberately dumb: translate events into engine calls, translate broadcasts into assigns:

def mount(%{"room" => room}, _session, socket) do
  if connected?(socket) do
    GameSystem.ensure_room(room)                 # find-or-start (Book 3)
    Phoenix.PubSub.subscribe(MyApp.PubSub, "game:" <> room)
  end
  {:ok, assign(socket, room: room, game: GameSystem.get_game(room))}
end

def handle_event("mark", %{"i" => i}, socket) do
  GameSystem.mark(socket.assigns.room, socket.assigns.player, String.to_integer(i))
  {:noreply, socket}                               # note: no assign here!
end

def handle_info({:game_updated, game}, socket) do
  {:noreply, assign(socket, game: game)}           # ALL updates come through broadcast
end

5. Taking it to production

The notebook version runs in Phoenix Playground. Making it real:

6. Your map from here

Where to go deeper (the sources this series was built from, roughly in order):

The end (of the beginning)

Six books ago, = didn't mean what you thought it meant. Now you can design a system where a million users each get their own supervised process and a crash is a non-event. The mental model you built — immutable data, message-passing processes, supervision as architecture, UI as process state — is the whole thing. Everything else in the ecosystem is a library away.