// the find
centrifugal/centrifuge
Real-time messaging library for Go. The simplest way to add feature-rich and scalable WebSocket support to your application. The core of Centrifugo server.
Centrifuge is a Go library for building real-time messaging infrastructure — WebSocket, SSE, and HTTP-streaming in one package, with horizontal scaling via Redis. It's the engine under Centrifugo server and Grafana Live, so it's production-tested at real scale. Aimed at Go developers who want to own their real-time stack rather than run a separate service.
1. The transport story is genuinely complete: bidirectional WebSocket (JSON + Protobuf), HTTP-streaming, SSE, and gRPC unidirectional — plus a WebSocket emulation layer that doesn't require sticky sessions, which is a real operational pain point solved properly. 2. Redis broker is well-engineered: consistent sharding, Sentinel, Cluster, and optimized Lua scripts for history/presence — not bolted on. 3. Message recovery on reconnect is built into the protocol, not an application-level afterthought. Combined with the history stream, clients can resume without hammering your database. 4. SDKs exist for JS, Go, Dart, Swift, Java, and Python, all implementing the same behavior spec — so the client side isn't a DIY project.
1. No v1 release, and the README says minor version bumps can break the API. That's fine for Centrifugo (which pins it), but adopting this directly in your own service is a real stability risk — you're one minor bump from a surprise refactor. 2. The history stream is explicitly not meant to be your primary missed-message store — you still need an app database for reliable delivery. The documentation is honest about this, but it means you're building two systems, not one. 3. The callback-based event handler pattern (OnConnect → set handlers → return) is idiomatic for the library but unusual enough that new contributors will misread the lifecycle docs and wonder why events aren't firing. 4. Presence data lives in Redis with TTL-based expiry — at large channel sizes this becomes expensive, and there's no built-in cap or eviction policy, so you can silently blow up your Redis memory if channels get crowded.