Instead of keeping pid in a separate GenServer, You might use Registry. It will allow You to map pid by key. This solution will work in local, then You might switch for :global when going distributed.

Or send a (register) message when the worker starts?!

I think that this points in the right direction, at least in the beginning. Registry is a more advanced use case. It may be best to start with a more restricted named process.

See Process.register/2 and GenServer name registration with the GenServer.start_link/3 :name option.

• It probably makes the most sense that it’s the monitoring process that is named. Typically worker processes are kept fairly generic. So the worker processes would have to “check in” (register) with the monitoring process. In terms of supervision an additional supervisor may be required to ensure that the monitoring process is up and running before any of the workers start. A :rest_for_one supervisor could start up the monitoring process first and the DynamicSupervisor second.

• Each worker process needs to check in with the named monitoring process before it does anything else. However a server’s init/1 callback is supposed to be kept as short/fast as possible as it will block the process that is calling start_link/3/start/3. So it would be best to return the new {:ok, state, {:continue, continue}} value from init/1.

• That will cause the handle_continue/2 callback to run - from within the new process (not under the start_link/3/start/3 process). Here the new process can call/3 the monitoring process by name. A cast/2 wouldn’t ensure that the monitor process is 1) up and running and 2) has processed the message. Once that call/3 completes successfully the worker process is free to go about it’s regular job.

• When the monitoring process receives a worker’s registration message it can use Process.monitor/1 to be notified when that particular process goes :DOWN so that it can be cleaned out of the monitoring process’s state.