FastPubSub Network
Ausfallsicheres Realtime-Pub/Sub über das globale Internet
Ausfallsicheres Realtime-Pub/Sub über das globale Internet
Early Access: Core-Mesh, gemessenes Routing und scoped Access Tokens sind live. Wir härten für externe Tester nach.
FastPubSub ist ein globales Realtime-Messaging-Netzwerk für Live-Daten, die weiterlaufen müssen: Games, Dashboards, Collaboration, Market Feeds, Control Signals und Browser-zu-Backend-Kommunikation.
Anders als Queues und Broker speichert FastPubSub keine Nachrichten. Es hält den Zustellpfad am Leben, indem Traffic über den schnellsten gemessenen Overlay-Pfad geroutet wird.
Andere Plattformen legen Zuverlässigkeit über das öffentliche Internet. FastPubSub repariert BGP nicht — es leitet schlechte Momente über ein gemessenes Overlay-Mesh um. Wenn ein Pfad ausfällt, leitet das Mesh in Sekunden um.
Wenn ein Kabel, Peering-Punkt oder ISP-Pfad ausfällt, konvergiert das Overlay auf alternative Routen, während Live-Delivery weiterläuft.
Pfade werden nach live RTT, Jitter und Loss gewählt — nicht nach dem, was BGP gerade bevorzugt.
Keine Persistence, kein Durable Log. Gebaut für das nächste Sample, nicht das letzte. Verlust ist akzeptabel; Stalls nicht.
Pfad-Zuverlässigkeit vs. Daten-Zuverlässigkeit
Eine Realtime-App sendet das nächste Sample, nicht das letzte. Der Moment zählt mehr als das Byte. Über ein verlustbehaftetes Netz kann man nicht gleichzeitig begrenzte Latenz und null Verlust haben.
Verlorene Bytes retransmitieren, auf ACKs warten, In-Order erzwingen. Ein verlorenes Paket kann alles dahinter stoppen. Wenn der Retransmit ankommt, ist das Sample veraltet.
Richtig für Dateitransfer und Durable Logs. Falsch für Live-Signale.
Applikationsnachrichten nicht retransmitieren. Das Budget in einen funktionierenden Pfad investieren, wenn der aktuelle degradiert. Während Reconvergence gehen Nachrichten verloren — der Stream erholt sich.
Fire-and-forget auf dem Hot Path, über QUIC-Relay-Backbone zwischen Regionen.
Wir garantieren nicht jede Nachricht — wir garantieren den Pfad.
Resilienz
Die meisten Messaging-Plattformen definieren Zuverlässigkeit als „jede Nachricht kommt an.“ FastPubSub definiert sie als „der Stream läuft weiter.“ Kabelbruch, Rechenzentrum-Ausfall, BGP-Flap, DDoS am Peering — das Mesh findet einen anderen Pfad.
Empfangen, autorisieren, routen, zustellen — einmal im Speicher, ohne Storage-Schicht oder Replay-Puffer.
Fire-and-forget: rein, durch das Mesh, raus.
Beim Verbindungsaufbau erhält der Client nahe Edge-Standorte, testet sie live und verbindet sich mit dem schnellsten erreichbaren Edge.
Der erste Hop wird gemessen, nicht hart auf eine Region festgelegt.
Qualität, Latenz, Loss und Last werden kontinuierlich zwischen Data-Center-Pfaden gemessen.
Bei Degradation oder Kabelausfall konvergiert das Overlay in etwa fünf Sekunden auf alternative Routen — während Live-Delivery weiterläuft.
Nachrichten laufen durch die Relay-Fabric und werden nahe den Listenern verteilt.
Ein ausgefallenes Relay stoppt die Zustellung für den Rest des Mesh nicht.
Autorisierung ohne transkontinentale Round Trips. Schnelle lokale Token Stores in wichtigen geografischen Konzentrationspunkten.
Master-Keys nicht auf jeden globalen Node verteilt. Control Plane vom Transit-Traffic isoliert.
So funktioniert es
Im globalen Netz ist Traffic nie gleich. Das öffentliche Underlay arbeitet nach Best-Effort. FastPubSub ändert das mit drei architektonischen Entscheidungen.
Typisch 5–25 ms gespart auf Inter-Region-Routen — Benchmarks ansehen.
Applikationsnachrichten früh ins Overlay und über Cloud- und Provider-Backbones, wo solche Pfade zwischen Regionen existieren.
Kontinuierliche Messung von Latenz, Jitter und Loss. Bei Degradation wählt das Overlay eine andere gemessene Route.
Traffic am nächsten Edge-Relay aufnehmen und für den Inter-Data-Center-Weg in der Relay-Fabric halten.
Routing nach live RTT, Jitter und Loss — nicht nach Hop-Count.
QUIC über UDP zwischen Relays; Overlay umgeht BGP-Umwege und überlastete Interconnects.
WebSocket-Messaging für Browser und Services. Logische Channels für Live-Delivery am Edge.
Nahe Edges beim Connect; Client testet live und wählt den schnellsten.
Planet-weit oder regional nach Bedarf.
Rust- und JavaScript-SDKs. WebSocket heute, QUIC für Clients geplant.
State-Updates, Sessions und Player-Events, bei denen Jitter und instabile Pfade sichtbar sind.
Dashboards, Feeds und Live-API-Updates für viele verbundene Nutzer ohne Origin-Overload.
Origin Shielding, scoped Tokens, Active-Active-Backends, Tenant Isolation.
Teams, die Events zwischen Regionen bewegen und den Stream bei schlechter Internet-Qualität am Leben halten müssen.
Ein Mesh, das einzelne PoP- und Link-Ausfälle überlebt.
WebSocket am Edge (QUIC für Clients geplant) · QUIC-Relay-Backbone · keine Persistence auf dem Hot Path
Nachrichten durch die Relay-Fabric, Fan-out nahe den Listenern.
Keine globale Ordnung über einen Channel. Langsame Listener stoppen schnelle nicht.
Viele-zu-viele und hoher Fan-out. Durchsatz skaliert mit Relay-Kapazität.
Rust- und JavaScript-SDKs. Einfache Pub/Sub-API.
Auf einem Mesh bauen, das umleitet, wenn das Internet nicht mitspielt.