Erlang Best Practices: Supervision, OTP, and Fault Tolerance

Erlang was designed at Ericsson for telecom switches that needed to run for years without downtime, and its best practices flow directly from that goal: the BEAM virtual machine gives every unit of concurrency its own lightweight process with isolated memory and no shared state, so a single crash can never corrupt a neighboring process. OTP (Open Telecom Platform) codifies these practices into behaviours — gen_server, gen_statem, supervisor, application — so instead of inventing your own process lifecycle, you plug business logic into a proven skeleton for state, restart, and error handling.

The 'let it crash' philosophy means you should not write defensive code to catch every conceivable error inside a worker process; instead, let the process terminate abnormally and rely on its supervisor to restart it into a known-good state. A supervisor is configured with a restart strategy: one_for_one restarts only the child that died, one_for_all terminates and restarts every sibling child (useful when children share tightly coupled state), and rest_for_one restarts the failed child plus every child started after it in the supervision tree's start order, leaving earlier siblings untouched. Getting the strategy right is a design decision about the dependency direction between children, not a cosmetic choice.

A gen_server serializes all messages to a process through one mailbox, so handle_call/3 must return quickly because the calling process blocks until you reply — doing a slow database query or HTTP request inside handle_call stalls every other caller waiting on that same server. The idiomatic fix is to do the expensive work asynchronously: reply immediately with {noreply, State} and send the real answer later via gen_server:reply/2 from a spawned helper, or route fire-and-forget work through handle_cast/2. handle_info/2 exists for messages that did not arrive through gen_server:call or gen_server:cast, such as 'DOWN' monitor notifications, timeouts scheduled with erlang:send_after/3, or raw messages from a linked process.

Erlang's process dictionary (put/2, get/1) stores state that is local to a single process and invisible to introspection tools and hot code reloads, so stashing anything beyond throwaway scratch values there tends to hide bugs and breaks the OTP convention that a process's real state lives in its gen_server State argument. For state that many processes need to read concurrently — a configuration cache, a session table, a rate-limit counter — ETS (Erlang Term Storage) is the standard tool: it is a separate, mutable table living outside any single process's heap, and readers can query it directly with ets:lookup/2 without funnelling every read through one gen_server's mailbox, which would otherwise become a serialization bottleneck under load.

Good Erlang error handling favors pattern matching over exception handling: functions return tagged tuples like {ok, Value} or {error, Reason}, and callers pattern-match on the shape they expect, letting an unexpected shape crash the process rather than silently continuing with bad data. try ... catch should be reserved for boundaries where you genuinely expect failure and can do something specific about it — a call into a NIF, a port program, or a third-party library with undocumented exceptions — and even then you should catch the narrowest class you can (catch error:{badmatch, _} is more honest than catch _:_), because a blanket catch-all hides bugs that should have crashed and paged someone.

Dialyzer performs success typing against -spec annotations on exported functions, catching type mismatches such as passing an integer where a function expects a tuple, without requiring the exhaustive static type system Erlang was deliberately built without; running Dialyzer in CI on every merge catches classes of bugs unit tests miss. observer gives a live view into the running system — the supervision tree, per-process message queue length and memory, ETS table contents — invaluable for diagnosing a production node without stopping it. For deployment, rebar3's release tooling (built on relx) assembles your application and its dependencies into a self-contained OTP release with a boot script rather than shipping loose .beam files; and within that release, worker processes should always be started under a supervisor via supervisor:start_child/2 or a static child spec instead of a naked spawn/1, because an unsupervised process that crashes leaves no trace and no automatic recovery.