RevenProx vs. the alternatives
Choose RevenProx when you want self-hosted, brokerless SSE fan-out at internet scale without per-message fees. Rolling your own gives maximum control but makes you build and operate the hard parts — connection handling, fan-out, and cross-node state. Managed pub/sub (Pusher, Ably, Redis pub/sub, and similar) removes the operational burden but bills per message/connection and moves your traffic through a third party. RevenProx aims to give you the managed-service scale profile while keeping ownership, the data path, and the bill under your control.
| Dimension | RevenProx | Roll your own SSE | Managed pub/sub |
|---|---|---|---|
| Deployment model | Self-hosted single Zig binary; brokerless NNG mesh you own end to end. | Self-hosted, but you build and maintain the fan-out and state layer yourself. | Fully managed SaaS; you send messages and let them handle delivery. |
| Scaling to millions | Designed for 10M+ concurrent connections across 100+ instances; add nodes to the mesh. | Achievable, but you own the hard parts — connection handling, fan-out, cross-node state. | Handled for you, but throughput and connections are billed and quota-limited. |
| Central broker | None. Peer-to-peer mesh with no coordinator to bottleneck. | Usually a broker or shared store (e.g. Redis) that becomes the scaling ceiling. | A broker exists — it is just operated by the vendor, and priced accordingly. |
| Cost model | Cost of the servers you run. No per-message or per-connection fees. | Your engineering time plus the infrastructure you provision. | Per-message / per-connection / per-peak pricing that grows with your audience. |
| Per-connection memory | Low and predictable — Zig, no GC, tuned for idle-but-open streams. | Depends on your runtime; GC languages make millions of idle sockets expensive. | Not your concern (and not your control). |
| Auth | Webhook-based JWT verification with caching + circuit breaker, wired to your identity system. | Whatever you build. | Vendor auth model; typically token/keys with their own constraints. |
| Protocol | Server-Sent Events — a simple, one-way, HTTP-native streaming protocol. | Your choice (often WebSockets or SSE). | Often WebSockets and proprietary channels; SSE support varies. |
| Data ownership | Streams never leave your infrastructure. | Yours. | Traffic transits a third party. |
| License | Open source, MIT. | N/A (your code). | Proprietary. |
vs. rolling your own SSE
Putting Server-Sent Events behind a generic reverse proxy and a shared store is a fine way to start. It stops being fine at scale: you end up building targeted per-topic fan-out, cross-node state synchronization, connection pooling for millions of long-lived streams, and an auth path that does not fall over under reconnect storms — which is precisely the work RevenProx has already done (brokerless mesh, bloom/merkle/vector-clock sync, UUID topic routing, cached JWT auth with a circuit breaker). If you need this once, building it is a distraction; if this is your product, you still have to operate it.
vs. managed pub/sub (Pusher, Ably, Redis pub/sub, …)
Managed services are excellent at removing operational burden, and for small-to-medium fan-out they are often the right call. The tradeoffs show up at scale and around ownership: pricing is typically per-message, per-connection, or per-peak, so cost grows with your audience; your traffic transits a third party; and you inherit their protocol and quota model. Redis pub/sub in particular gives you a broker to run and, being fire-and-forget through a central node, a scaling ceiling to plan around. RevenProx trades "someone else runs it" for "you own it, brokerless, at a flat infrastructure cost."
Honest caveats
- You operate it. RevenProx is self-hosted infrastructure. If you would rather never run a mesh, a managed service is less work.
- SSE is one-way. If you need full-duplex, bidirectional messaging, SSE — and therefore RevenProx — is the wrong primitive; use WebSockets.
- It targets very large scale. The brokerless-mesh design earns its keep at high connection counts; a small app may not need it.