This text explains the limitations of using process PIDs as public interfaces and introduces named processes as a solution for discoverable addresses. When a worker crashes and restarts, it gets a new PID, making the old PID invalid. Sending messages to a dead local PID does not cause an error or restart the process. To address this, clients can depend on a name and resolve it when sending messages instead of using a PID.The article demonstrates two methods for naming processes: local registration and global registration. Process.register/2 registers a PID with a name on the current BEAM node, accessible via Process.whereis/1. Messages can be sent directly to the registered name, which the runtime resolves to the current PID. However, Process.register/2 is node-local, meaning the same name on different nodes refers to different processes.For cluster-wide lookup, the Erlang :global module is used. :global.register_name/2 and :global.whereis_name/1 allow registration and lookup of names across connected nodes. The third example shows how to hide the PID from clients by having the worker register itself and return its public name. The client then sends requests to the name, not the PID.Crucially, naming processes does not solve supervision or lifecycle management; it only addresses discovery. When a registered process terminates, its registration is removed, and a replacement must be started and re-registered. A single name typically refers to a single owner, making it unsuitable for worker pools without further routing mechanisms. Correlating replies using unique references is recommended for clients with multiple requests in flight. Finally, :global registration facilitates distributed systems but doesn't eliminate challenges like network partitions or concurrent claims. The core idea presented is to use process names for service roles rather than temporary PIDs to build resilient systems.