yup... all that's needed is some more experimentation with distributed dynamic cache strategies and more use of the pub/sub model... the sub side is there already, and can be relatively simply made to run, but push side needs to be there too, or at least, a model of subscription in which the emitted events are in a queue and when a subscriber drops, they get sent the backlog they miss in the interim. this isn't really that complicated to implement either, in fact, i wrote a sub thing using SSE but all i have to do to make it resilient is create a primary subscription queue and progress monitoring of subscribers and a slightly different contract than the best effort that is the current standard.

Replies (1)

i will make this in my rewrite of realy too... it will be a relay side thing, a separate "sync" endpoint that will have a thread maintaining the IDs of recently stored events in a cache and per-subscriber queue state management that will always send events, and the receiver will ack them instead of the current scheme where it's fire and forget