FastPubSub

Ultra-low latency distributed messaging network

Roadmap

What we are working on now and what is coming next

Done — What Already Works

Core systems that are operational today

Done

Overlay Network & Relay Mesh

QUIC relay backbone is live. Dozens of stationary PoPs spread across the globe plus up to 40 anycast access points worldwide. Relays discover each other, establish encrypted tunnels, and form a resilient mesh.

Done

Pub/Sub & Channel Fanout

Publish/subscribe is working end-to-end. Writers publish to the nearest PoP, the relay mesh forwards along the best measured path, destination PoP fans out to all subscribed listeners.

Done

Access Tokens & Auth

Token-based authentication is in place. Clients receive access tickets with scoped permissions (publish/subscribe per channel). Tokens are validated on every PoP.

Done

Control Plane

Central management service is operational: tenant management, token issuance, configuration push to PoPs.

Done

Latency-Based Routing

Relays continuously measure RTT between each other and compute fastest paths using Distance Vector. Traffic is routed through the lowest-latency path in real time.

Done

Live Monitoring Dashboard

dashboard.fastpubsub.com — real-time world map of PoPs, overlay vs direct latency comparison, network anomaly detection. Uses our own FastPubSub infrastructure to deliver live updates to the browser.

Now — Active Development

Core infrastructure and tools needed before public launch

In progress

Analytics & Metrics

Per-PoP and per-channel metrics: message rates, connections, latency histograms, GeoIP, bot detection. Prometheus export + internal dashboards.

In progress

Eliminate Single Point of Failure

This is a key target of the project and work in this direction has been ongoing since day one. The current architecture still has a single point of failure that needs to be resolved. Goal: fully distributed/redundant model with replicated control plane, multi-path relay failover, and no single node whose loss breaks the system.

Planned

Client SDKs

Lightweight libraries for JavaScript/TypeScript, Python, Go, Rust, C#, Java. Auto-reconnect, channel subscribe/publish, token refresh.

Planned

Admin Dashboard (UI)

Web UI for tenant owners: manage channels, view live metrics, create tokens, see connection map. Built on top of Control Plane API.

Planned

Rate Limiting & Abuse Protection

Per-tenant and per-channel rate limits (msg/s, bytes/s, connections). Backpressure, slow-consumer drop policy, IP-based throttling.

Planned

Documentation & Guides

Getting started guide, API reference, integration examples, security best practices, deployment guide for self-hosted scenarios.

Planned

Billing & Usage Tracking

Message counters per tenant, usage aggregation, quota enforcement. Foundation for paid tiers and metered billing.

Future — Ideas & Exploration

Concepts we are thinking about. Not committed yet, but high potential.

Idea

Presence & Channel Info

Who is online in a channel, subscriber count.

Idea

Edge Inbox Endpoint

A ready-made HTTPS endpoint on the nearest PoP where clients can POST events. We turn them into channel messages and fan out to listeners instantly. Universal webhook receiver with zero infrastructure for the client.

  • Webhook concentrator for SaaS (Stripe, GitHub, CI/CD)
  • Edge ingestion for IoT and agents (HTTP POST only)
  • HMAC signatures, rate-limit, dedup, routing rules
  • "POST once, fanout instantly"
Idea

Protocol Bridges

FastPubSub as a "network adapter" between external protocols and our channels. Connect existing systems without rewriting them for our SDK.

  • Webhook ingress/egress (any webhook ↔ channel)
  • SSE read endpoint (subscribe without SDK)
  • MQTT bridge (IoT devices ↔ channels)
  • Kafka, NATS, Redis PubSub compatibility (later)
Idea

Private Edge Gateway

A customer-hosted node inside a private network. Exposes local WebSocket/HTTP endpoints and maintains an outbound-only mTLS tunnel (WebSocket or gRPC over TLS) to the FastPubSub fabric. No inbound firewall ports needed.

  • Docker / Kubernetes (Helm chart) deployment
  • Outbound-only: no inbound ports from Internet
  • Edge rules: filter, route, throttle, transform
  • Enterprise add-on: mTLS, RBAC, audit log
Idea

GameDev: QUIC/UDP Transport

QUIC DATAGRAM as an additional transport option alongside WebSocket streams and QUIC streams. Unreliable delivery mode for real-time state updates and fast control signals where "latest matters, not every packet".

  • QUIC DATAGRAM on top of existing WebSocket/QUIC stream transports
  • MTU-safe default ≤1200 bytes, optional large messages
  • seq/tick/drop-old policies for predictable game state
  • Edge relay fallback for problem networks (lag spikes, DPI)
  • Adaptive tick rate, quality metrics in SDK
  • Spatial subscriptions via geohash: player position → auto-subscribe to nearby cells/events
  • Topologies: dedicated server→players, player input→server, spectators