FastPubSub Network
Resilient realtime pub/sub over the global Internet
Resilient realtime pub/sub over the global Internet
FastPubSub is not a queue or a durable log. It is a resilient live-delivery fabric: path reliability when Internet routes fail, not data reliability through retries and replay.
Use durable brokers when every message must arrive. Use FastPubSub when the stream must keep flowing even if individual samples are lost during reconvergence.
You need durable logs, replay, retention, and stream processing with historical data.
You need queue semantics for work distribution, acknowledgments, and brokered task processing.
You need lightweight broker messaging, request/reply patterns, and internal service transport.
The stream must survive Internet path failures — cable cuts, BGP flaps, peering outages — not when every message must be replayed from a durable log.
FastPubSub reroutes in seconds when underlay paths degrade. It does not retransmit lost application messages or buffer for replay. Stalls are worse than loss for live signals.
Connect via WebSocket and publish. No regional broker clusters, storage tiers, or path measurement to operate yourself.
When a path fails, FastPubSub measures alternates and reroutes in about five seconds. Durable brokers typically keep using the same broken underlay and mask loss with retries and buffers.
FastPubSub treats messaging as a UDP-style flow: the next sample matters. Kafka and similar tools treat messaging as a TCP-style stream: every byte must arrive, even if stale.
No persistence, replay, consumer groups, or global ordering — by design. If you need those, use a durable broker and accept underlay routing as-is.
Use durable brokers for storage and replay. Use FastPubSub when the stream must survive path failures.