I run a startup called https://tallyfy.com and we actually use PubNub, but without CF workers - so none of the “compute at the edge” benefits are possible at present, even though we’re rather excited about the possibilities, just like you are!
I think if someone built a service that laid over something like Google Cloud Spanner, you might at least have a decent persistence layer underneath that’s more reliable to many writes/reads. It seems you only need to think about post-write fan-out.
In other words, to update multiple listening clients on PubNub in real-time (to me) - the simplest architecture is just a matter of knowing that sockets/channels exist and then pushing a post-write update to all those listening clients to tell them to “fetch this object ID and update yourself”. That would avoid polling.
From what I understand of your use case, it’s only writes that really need updates to all listening clients.
We’re playing with more ideas on how we might use Workers in other ways too, but some of the essential primitives are missing. We intend to post our updates on architecture on our tech page, btw, in case we ever implement something awesome via CF workers:
Right now - long-lived caching seems the most obvious use case. In an app like ours, not many objects are long-lived and/or don’t change very often. Even if they were, it’s easier to just make a static version of them and cache via standard CDN or push via Cloudfront, etc.
One more use case you might really like - we started using Moesif to log all API calls at the edge. They have a Cloudflare add-on, and that might add value straight away if your app is API-first. Think of that as real-time logging of API calls, at the edge.