go-ws-server
A stateless WebSocket server in Go with Redis as its only coordination point: pub/sub topics with replay, topic locks, per-user broadcast and a distributed job scheduler.
What it does
It grew out of the WebSocket server I built at Console One. Every publish goes to a capped per-topic Redis Stream for history and to Redis Pub/Sub for live fan-out, so you scale by adding instances behind any load balancer. Late subscribers replay what they missed from a timestamp, a stream ID or their last acknowledged position, deduplicated against live traffic.
It runs as a standalone server or embeds as a Go package, with pluggable authentication and per-topic authorization, a Judge hook that makes a routing decision per message at publish time (which semantic-pubsub uses), custom protocol verbs and middleware. A distributed scheduler runs delayed and recurring HTTP calls, claimed atomically so each job runs once, with SSRF protection checked when the connection is dialled rather than only on the URL.
On one instance, 500 subscribers at 200 publishes a second took 250,000 deliveries with none lost, at a p50 of 2.5ms. An unthrottled burst of a million deliveries lost nothing: latency degraded, not data. The limit at scale is Redis's outbound bandwidth, about 10 instances at 10,800 messages a second on a 1 Gbps link. That's far beyond what it needs, so I measured it and chose not to add sharded pub/sub yet.
- +Token expiry enforced for the life of the socket
- +Prometheus metrics, a Grafana dashboard and slow-consumer eviction
- +Redis single node, Cluster or Sentinel