Building Distributed Systems in Elixir: Part 6 — Named Processes

The article explains why sharing a PID is fragile: a PID points to one running incarnation, so it works for replies, monitors, and links, but not as a stable service address after a crash and restart. It then introduces named processes as a way for callers to depend on a service role instead of a temporary PID.

Reading notes

#

• A worker can be registered locally with Process.register/2, then found with Process.whereis/1 or addressed directly with send/2 using the name.
• Local registration belongs to one BEAM node, so the same name can exist on different disconnected nodes without conflict.
• :global.register_name/2 and :global.whereis_name/1 provide node-wide lookup for connected nodes, but the article notes that global coordination has operational trade-offs.
• The worker can register itself and return :worker instead of its PID, so clients send requests to the name and keep the caller PID only for the reply path.
• Names do not replace supervision: when a registered process exits, its name is removed and a replacement still needs to be started and registered.
• One local name maps to one owner, so this simple mechanism fits a singleton service but not a worker pool.
• For reply correlation, the article shows matching on the request value and suggests make_ref() when several requests may be in flight with the same value.
• The closing point is that naming helps discovery, while supervisors handle lifecycle, and distributed systems still need decisions about partitions, duplicate claims, and dead PIDs.

Series

#

Building Distributed Systems in Elixir, by krishnadaspc. Research: Distributed Systems Patterns.

• Part 1 — Stateful Process Without GenServer
• Part 2 — Correlated Request–Reply
• Part 3 — Process Monitoring
• Part 4 — Process Linking
• Part 5 — Supervisor From Scratch
• Part 6 — Named Processes
• Part 7 — Worker Pool
• Part 8 — Publish / Subscribe
• Part 9 — Backpressure