Real-time messaging over measured low-latency paths
Looking for the Python FastPubSub library? Check it out here.
This project is currently under development
For latency-sensitive real-time apps where direct Internet routing is sometimes suboptimal.
FastPubSub routes around overloaded interconnects and BGP detours in real time to keep delivery fast and stable, especially across regions, ISPs, mobile networks, and difficult enterprise edges.
of measured routes show stable latency improvement.
typical win on bad paths where direct routing is suboptimal.
Cross-region traffic, mixed ISPs, mobile users, and stressed interconnects.
Improvement: 20 ms (avoiding congested peering)
Built entirely in Rust for high performance, memory safety, and low overhead.
Our relays dynamically route packets based on real-time latency measurements (RTT), not hop count.
Uses QUIC over UDP between relays to form an overlay mesh that can route around BGP detours and congested interconnects.
Easy integration for clients via standard WebSockets. Logical channels instead of raw TCP streams.
Start coding in minutes with our lightweight SDKs for major languages. No complex configuration required.
Built on open standards: WebSocket for edge connectivity (QUIC planned for clients) and QUIC for the relay backbone.
For state updates, session coordination, and user-facing interactions where jitter and unstable routes quickly affect user experience.
For workloads that move events between regions and need predictable delivery when direct Internet routing quality changes over time.
For channels that deliver the same event to many listeners and need lower-latency paths across mixed ISPs, mobile networks, and congested interconnects.
Engineer note: WebSocket edge (QUIC planned) · QUIC relay backbone · Online-only fanout (no persistence)
BGP is built for reachability, not speed. It can pick longer or congested routes. Our relays continuously measure RTT, jitter, and loss. If a path degrades, we recompute routes in seconds and steer traffic to a better hop.
Pure fire-and-forget delivery. No disk persistence means fewer moving parts and no storage bottlenecks—messages flow from Writer to Listener without hitting a database.
FastPubSub is message-oriented, not stream-oriented. We don't enforce global ordering across a channel, so there is no single serialized queue that every message must wait behind. Each subscriber has independent flow control—slow listeners won't stall fast ones.
Messages are forwarded through the relay fabric and fanned out near listeners, avoiding unnecessary central bottlenecks.
Drop-in SDKs. WebSocket today, QUIC for clients planned. QUIC relay backbone. Simple Pub/Sub API. Focus on your app logic, not networking code.
Designed for many-to-many communication and high fan-out delivery. Practical limits depend on route quality, message size, and workload patterns.
The core is operational: QUIC overlay mesh, latency-based Distance Vector routing, and access ticket authentication are all working. We are hardening these components and preparing for the first external testers.
New: dashboard.fastpubsub.com is live — a real-time monitoring dashboard showing our overlay network, latency savings, and network anomalies on a world map. We are also preparing the first SDKs for easy integration.
Clients (Writers/Listeners) connect to our relays via WebSocket. Authentication and channel logic happen here.
The message enters the network. Our relays use Distance Vector routing with latency metrics to forward data through a lower-latency measured path available at that moment.
Data reaches the destination relay and is pushed to subscribed Listeners immediately.
Join our early access program and start routing around the public Internet's traffic jams.