FastPubSub Network
Resilient realtime pub/sub over the global Internet
Resilient realtime pub/sub over the global Internet
Early access: core mesh, measured-path routing, and scoped access tokens are live. We are hardening for external testers.
FastPubSub is a global realtime messaging network for live data that must keep moving: games, dashboards, collaboration, market feeds, control signals, and browser-to-backend communication.
Unlike queues and brokers, FastPubSub does not store messages. It keeps the delivery path alive by routing traffic through the fastest measured overlay path.
Other platforms add reliability on top of the public Internet. FastPubSub doesn't fix BGP — it routes around bad moments through a measured overlay mesh. When a path fails, the mesh reroutes in seconds.
When a cable, peering point, or ISP path fails, the overlay converges on alternate routes while live delivery continues.
Paths are chosen by live RTT, jitter, and loss — not by what BGP happens to prefer right now.
No persistence, no durable log. Built for the next sample, not the last one. Loss is acceptable; stalls are not.
Path reliability vs data reliability
A realtime app sends the next sample, not the last one. The moment matters more than the byte. Over a lossy network you cannot have both bounded latency and zero loss — you choose a mechanism.
Retransmit lost bytes, wait for ACKs, enforce in-order delivery. One lost packet can stall everything behind it. By the time the retransmit arrives, the sample is stale.
Right for file transfer and durable logs. Wrong for live signals.
Do not retransmit application messages. Spend that budget on finding a working path when the current one degrades. During reconvergence some messages may be lost — the stream recovers.
Messages are fire-and-forget on the hot path, carried over a QUIC relay backbone between regions.
We don't guarantee every message — we guarantee the path.
Resilience
Most messaging platforms define reliability as “every message arrives.” FastPubSub defines it as “the stream keeps flowing.” Cable cut, data-center outage, BGP flap, DDoS on a peering point — the mesh finds another path and keeps moving traffic.
The hot path does four things: receive, authorize, route, and deliver. Each message is handled once in memory and moves on — no storage layer, no replay buffer.
Fire-and-forget on the data path: in, through the mesh, out. Fewer moving parts, fewer places where milliseconds are lost.
At connect time, the client receives a shortlist of nearby edge locations, races them with live latency checks, and attaches to the fastest reachable edge.
The first hop is selected by measurement, not by a hardcoded region.
Routes are treated as a living system. FastPubSub continuously measures quality, latency, loss, and load across backbone paths between data centers.
If a path degrades or a physical link fails, the overlay converges on alternate routes in about five seconds across the global mesh — while live delivery keeps moving.
Messages move through the relay fabric and fan out near listeners instead of passing through one central choke point.
Losing one relay does not stop delivery for everyone else on the mesh.
Authorization should not create transcontinental round trips. FastPubSub places fast local token stores in key geographic concentration points.
Session and token data is synchronized across the network, so authorization can happen close to clients while the system keeps a consistent control view.
Master encryption keys are not distributed across every global node, reducing the blast radius of node-level compromise.
The control plane is isolated from transit traffic. Working routes keep carrying traffic even while control services or whole cloud regions are recovering.
How it works
On the global network, traffic is never equal. The public Internet underlay works on a best-effort basis. FastPubSub changes this with three architectural choices.
Typical 5–25 ms saved on inter-region routes where direct Internet paths are congested or detoured — see benchmarks.
Global links carry huge volumes of bulk traffic. At transit routers, packets can wait in shared buffers and lose milliseconds.
FastPubSub moves application messages into an overlay early and steers them through commercial cloud and provider backbones where such paths exist between two regions.
Classic Internet routing is optimized for reachability and policy, not always for the fastest physical path.
FastPubSub continuously measures latency, jitter, and loss between relay locations. When the default path degrades, the overlay selects another measured route.
Many providers hand traffic to another network as quickly as possible, adding jitter and extra latency at public exchange points.
FastPubSub brings traffic onto the nearest edge relay and keeps it inside the relay fabric for the inter-data-center path.
Relays route by live RTT, jitter, and loss measurements — not hop count or static topology.
QUIC over UDP between relays forms an overlay that can route around BGP detours and congested interconnects.
Global WebSocket messaging for browsers and services. Logical channels for live delivery at the edge.
On connect, bootstrap returns nearby edges; the client races them and picks the fastest by live ping.
Use FastPubSub across the planet, or keep traffic in one region when your workload requires regional scope.
Rust and JavaScript SDKs. WebSocket today, QUIC for clients planned. No complex broker configuration.
State updates, session coordination, and player interactions where jitter and path instability are visible to users.
Dashboards, customer feeds, market data, and live API updates that need to reach many connected users without overloading the origin.
Origin shielding, scoped access tokens, active-active backends, tenant isolation, and enterprise reserved capacity.
Teams that move events between regions and need the stream to survive when direct Internet routing quality changes.
A mesh that survives individual PoP and link failures — traffic reroutes when standard Internet paths fail.
WebSocket at the edge (QUIC for clients planned) · QUIC relay backbone · no persistence on the hot path
Messages are forwarded through the relay fabric and fanned out near listeners, avoiding unnecessary central bottlenecks.
FastPubSub does not enforce global ordering across a channel. Each subscriber has independent flow control — slow listeners won't stall fast ones.
Designed for many-to-many communication and high fan-out delivery. Throughput scales with relay capacity; see benchmarks for measured numbers.
Rust and JavaScript SDKs available now. Simple pub/sub API. Focus on application logic, not networking code.
The core is operational: QUIC overlay mesh, measured-path routing, and scoped access tokens are all working. We are hardening these components and preparing for the first external testers.
New: the JavaScript SDK is available on
npm
(@fastpubsub-sdk/client), alongside the Rust SDK on
crates.io.
Start building on a mesh that reroutes when the Internet doesn't cooperate.