So i promised a longer answer, but i see that @tristan answered already quite like i was going to.
I will add my voice to the chorus of “avoid single process if possible”. It seems you want both “always show latest” and “never send the same message twice”. Now the question is, how many messages can you afford to not notify on? And how much can you afford to lose some messages because a node went down ?
Depending on the answer to these, you will have different needs. If you can afford to lose a node and all the live data on it and possibly lose some messages, then it is easy, you can simply use your “global” process and use something like Swarm.
If you cannot accept these two constraints, then you enter the realm of tradeoff, because you will need to have some redundancy in your data. Which means that you get consistency problems. There are no “simple” answer there, it will be up to you to find how to do it.
In your case, you also have an ordering problem. I will suppose that you already have a function that allows you to order. I will guess it is timestamp based. Beware of that. In a distributed system, the clock of your machines will not be aligned. You may accept some errors there and decide it is good enough if you do not have high tempo data. It depends of how much you can afford to lose in term of ordering.
Otherwise, you will need to define a distributed order. That is far more complex and will also inform your design.
I think at that point, you will need to reach to people with experience handling this kind of things i would say. Because all answers will depends on your particular business logic needs. Someone offered Erlang-Solutions, there are others. Disclaimer: i may be biased here as i offer these services too.
PS: As a final note for the problem of the “single global process”, @keathley has a good blogpost on the danger of it The dangers of the Single Global Process
