I think you need to be aware of that when a process dies it completely goes away and everything in it like memory and messages is lost. A process cannot be restarted, ever! When we say a supervisor restarts a crashed process what we actually mean is that the supervisor creates a completely new process to take its place.

If you didn’t want to involve Oban and the db you can isolate things much better than sending a process a bunch of messages to a worker process.
Create one process that just holds the data list, if it’s simple enough it should never crash (lol) then do all of the processing inside a different process. It would take one event at a time, so even if it crashed you would lose that bad one at worst. You could even monitor the process and re add the data in case of a crash. But none of these would survive a machine reboot. For that you need to write it somewhere.
Postgres and Oban would work, as would pushing each message in SQS and letting Broadway pull them out. Each solution has its place depending upon your requirements.

Just wanted to add/highlight that it’s not just when the machine restarts, it’s when the process ends for any reason.

Nothing is done with it, it is only in memory as long as the process is running (and the node is alive, etc).

If you want durable messages / reliable delivery / etc, you’ll need to explicitly set that up.

What specifically do you mean by “external” in this context?

This description needs more detail to narrow down the possible implementations:

• Oban could be viewed as a version of this: an “external” message inserts a job, which is then routed to a worker process
• so could Kafka, although the “send a message” part is replaced with a “check for messages” interaction
• lots of others, from work-queues to durable append-only logs

Another challenge with introducing this kind of persistence is making sure that messages are replayable - for instance, GenServers are frequently used as “stateful containers” so you might see a sequence of messages like:

• message 1, set up some initial state
• message 2, do additional stuff with things created in message 1
• message 3, do final work and clean up state from message 1 and message 2

Just saving messages that haven’t been handled isn’t enough, since sending a restarted server “message 3” won’t have the state set up in the first two messages.