Client · Anonymised · Real-time messaging
200K concurrent WebSocket connections on bare metal, held for two years
A real-time messaging platform moved from a single overloaded VPS to a k3s cluster on bare metal, with a Node client library rewritten in Go. Two years later it still holds its client's connection floor.
200K+
90%
2 yrs
The problem
The platform's connection count had outgrown a single VPS. Every deploy meant dropped connections, the Node client library consumed memory faster than the business could add servers, and the managed-cloud quote for the same capacity would have tripled infrastructure spend.
What we did
Architecture assessment: connection patterns, message fan-out, and where memory was actually going.
k3s cluster on dedicated bare-metal servers with Cilium and eBPF networking to keep per-connection overhead low.
Rewrote the Node client library in Go; the same load ran in roughly a tenth of the RAM.
MongoDB with replicated storage, Grafana stack for observability, rolling deploys that keep connections alive.
Managed retainer: monitoring, patching, upgrades and on-call, against an agreed connection floor.
The result
WebSocket connections drop and reconnect constantly, so the client set two limits: reconnects must not arrive as a thundering herd, and at least 75% of connections must stay connected at all times. The cluster held both for two years, and in normal operation about 90% of connections stayed connected.
The client owns the server account, the cluster and every config repo.