Build a village of gnomes, not a park of machines.

Posted: 2025-11-07

Build a Village of Gnomes, Not a Park of Machines

In the last post, The Gnome Village, we explored how the BEAM turns concurrency into cooperation.

Gnomes represent processes, small, isolated workers with private memory, shared code, and clear message channels. They take fair turns at the workbench, recover from failure, and never share state.

The metaphor captures eight principles that together define the runtime:

1. Isolation: Private backpacks (per-process heaps).
2. Self-cleaning: Each gnome cleans its own backpack (per-process GC).
3. Async messaging: Paper mail in mailboxes (message passing).
4. Shared code: Scrolls on the shelf (hot code loading).
5. Lightweight: Cheap to hire (spawn costs microseconds).
6. Fair scheduling: Turns at the workbench (reduction-based preemption).
7. Fault isolation: One crash stays local (contained failures).
8. Supervision: Managers replace workers (recovery trees).

Workbenches are schedulers. Backpacks are heaps. Scrolls are modules. Mailboxes are message queues. It’s all real BEAM behavior, just viewed through a lens that focuses on cooperation instead of control.

Now we come to the eighth principle: Supervision.

Supervisors Are Managers

Structure work as teams with clear reporting.

In the gnome village, supervisors are the managers who keep the teams running smoothly. They don’t do the work themselves. They hire, monitor, and, when necessary, replace gnomes that fail.

Each supervisor watches over its workers. When one crashes, the supervisor decides what to do:

• Restart that worker.
• Restart the whole team.
• Or escalate the problem to a higher supervisor.

The supervisor links are actual process relationships. They are what give the BEAM its resilience.

In the machine world, there are no managers, only mechanical linkages. When one cog breaks, the force ripples through gears and seizes the whole system. Recovery means shutdown, repair, and restart.

In the gnome village, failure is expected. Supervisors define how much of the village must recover when something breaks. If a panini making gnome crashes, only the panini line restarts. Salad service continues. Customers barely notice.

How Supervisors Work

Under the hood, supervisors are just gnomes with a specific job: watch others.

Each worker process is linked to its supervisor. If it terminates unexpectedly, the supervisor receives an exit signal. What happens next depends on the restart strategy defined in the supervisor specification.

A few key concepts:

• One-for-one: Replace only the failed worker.
• One-for-all: Restart the entire group if one fails.
• Rest-for-one: Restart this worker and everyone started after it.
• Simple-one-for-one: Manage dynamically created, similar workers.

The supervisor itself runs in an endless loop, receiving status updates, reacting to crashes, and spawning replacements. It never panics, never crashes the system.

Who watches the Watchmen?

If a supervisor fail, it too has a supervisor. The chain continues up to the root of the system, forming a supervision tree.

The root supervisor is the top of your application. Each branch defines recovery boundaries. Together they form a living hierarchy that can self-heal.

The Observer

Supervisors are one of several process archetypes in the BEAM. They represent the Observer archetype, a process whose purpose is to watch something.

In the next post, we’ll explore these archetypes, from Workers to Servers to Supervisors, and see how each plays a role in building stable, comprehensible systems.

Until then: build a village of gnomes, not a park of machines.

• Happi