Architecture pattern for temporary message queue subscriptions with websocket clients

Question

We use Google Pub/Sub for event streams which we want consumed by transient websocket clients. What is a good pattern for creating subscriptions and cleaning them up when the client is no longer connected? The main use case is an admin portal where we want to update the display in real-time based on data change events.

Initial thoughts:

1. The clients won't reliably clean up after themselves on shutdown, so subscriptions should be cleaned up externally somehow when clients disappear
2. Each server node could create a topic subscription on startup and re-broadcast messages to interested clients, but the second part seems sort of like building a new message queue
3. In the case of (2), we still have a cleanup problem if nodes crash without deleting their subscription (though much less so than creating a subscription for each websocket client)

Is there a common architecture pattern (or existing project) that solves this problem?

Answer 1

If anyone runs across this, the easiest answer I found is to use Redis Pub/Sub for websocket clients. Since Redis doesn't have persistent subscriptions or guaranteed delivery, I have a client subscribed to the more reliable Google Pub/Sub and injecting certain topics into Redis Pub/Sub. The websocket clients subscribe via Redis, and they will only get messages sent from that point on (no backlog) and there is no subscription to cleanup after disconnect. Exactly the behavior I was looking for.