There is no global pubsub process. The VM guarantees message order for any messages sent between two process. So, if process A sends process B, :foo and then :bar, process B is guaranteed to receive them in that order. However if A sends :foo to B and then C sends :bar to B, it’s possible it could see them in any order, depending on how close together those sends happened.

When you broadcast!("some topic", value) you are basically acting as Process A, and you are sending to all processes that are subscribed to that topic. So, if you broadcast :foo and then broadcast :bar, that will arrive in the correct order to everyone.

Exacerbated, but it’s 100% possible even with one server for a variety of reasons.

For one thing, this ^ is a flawed assumption. Subscribers are stored in Registry, which uses a sharded set of :ets tables in :duplicate_bag mode. There is no real order guarantee here at all between any two invocations, plus the list itself can change between those invocations in a way that may effect the order.

Even if the order was a simple list somewhere, the BEAM simply doesn’t provide the guarantee you’re looking for. If the time between A and D messaging C is sufficiently small, then small differences like which scheduler each process is currently on can cause them to arrive out of order. Message order is only guaranteed between one process and another.

Thanks @benwilson512. I saw a PubSub.local0 genserver process in the erlang observer process tree and thought maybe it was “sending” messages to the socket processes I saw it was monitoring. But that’s not very elixir-ey. If anything, that PubSub process (or some other entity) would probably keep a registry of socket genserver pids within which broadcast! calls would ultimately call functions.

All that aside, I think I get it. Thanks a lot.