Im digitalen Zeitalter, in dem Datenströme in Echtzeit die Basis moderner Kommunikation bilden, gewinnt die effiziente Verteilung großer Eventmengen zunehmend an Bedeutung. Besonders im Ökosystem rund um Bluesky und das ATproto-Protokoll stellt die realzeitnahe Weitergabe von Ereignissen, wie Posts, Likes oder Follows, eine technische Herausforderung dar. Die steigende Anzahl von Nutzer*innen und die wachsende Menge an Daten verlangt nach Relays, die hochperformant, skalierbar und ressourcenschonend sind. Vor diesem Hintergrund hat sich Jetrelay als bemerkenswerte technische Lösung herauskristallisiert, die mit weniger als 500 Zeilen Code eine außergewöhnliche Effizienz beim Betreiben eines ATproto-Relays erreicht. Ihr Erfolgsrezept ist das intelligente Nutzen von Linux-Kernel-Funktionen und ein minimalistischer, aber durchdachter Designansatz.
Bluesky, eine Plattform, die auf ATproto basiert, nutzt sogenannte Firehose-Feeds als Backbone für die Verteilung von Änderungen und Ereignissen im Netzwerk. Diese Firehose stellt eine ununterbrochene, umfassende Datenquelle dar, die alles vom neuen Content über Löschungen bis hin zu Reaktionen abdeckt. Dabei gibt es zwei Varianten des Feeds: die umfassende, sogenannte Full-Firehose, und eine schlankere Version namens Jetstream. Jetstream ist speziell für eine optimierte Verteilung konzipiert und überträgt Daten im JSON-Format via Websockets, was es besonders zugänglich für verschiedenste Clients macht. Trotz der kleineren Eventgröße von ungefähr 500 Bytes und einer Ereignisfrequenz von mehreren hundert Events pro Sekunde stellt das Verarbeiten und Weiterleiten dieser Mengen an Daten eine enorme Belastung für Serversysteme dar.
Die technische Herausforderung besteht darin, diese Masse an Events effizient an eine große Anzahl von Clients zu verteilen, ohne dabei die Serverressourcen zu überlasten. Jetrelay begegnet diesem Problem mit einem simplen, aber leistungsfähigen Prinzip: Es speichert eingehende Ereignisse fortlaufend als eine Datei, in der Form, in der die Daten auch übertragen werden. Für jeden Client wird ein Cursor geführt, der auf einen bestimmten Offset in der Datei verweist. Wenn ein Client nicht auf dem aktuellsten Stand ist, sendet Jetrelay die noch ausstehenden Bytes direkt vom Dateisystem über das Netzwerkkabel – ohne aufwendige Zwischenschritte oder Datenkopien im Userspace. Dieses Trick basiert entscheidend auf dem Linux-Systemaufruf sendfile(), der es erlaubt, große Datenblöcke direkt aus dem Kernel-Puffer heraus an einen geöffneten Socket zu senden, ohne den Umweg über den Anwenderbereich zu machen.
Das bedeutet, dass Daten von der Datei zum Netzwerkinterface gelangen, ohne dass sie von der Anwendung aktiv gelesen und dann wiedergeschrieben werden müssen – eine effiziente Umgehung, die den CPU-Aufwand dramatisch senkt. Gerade bei Verteilung von identischen Daten an viele Empfänger spart diese Methode immens an Ressourcen, da die Daten nur einmal in den Kernel-Cache geladen werden. Die einfache Logik des Datei- und Cursor-Modells bringt neben Effizienz weitere Vorteile mit sich: Clients, die mit dem Feed hinterherhinken, können in größeren Datenblöcken aufgeholt werden, was die Anzahl der Systemaufrufe minimiert und die Latenz bei hoher Last reduziert. Außerdem ermöglicht dieses Design ein natürliches Batching der Schreib- und Leseoperationen, wodurch die Performance auch bei vielen gleichzeitig verbundenen Clients stabil bleibt. Da sendfile() jedoch ein synchroner Aufruf ist, der blockiert, bis die Übertragung abgeschlossen ist, könnte er ohne weitere Maßnahmen gerade bei langsamen oder nicht mehr reagierenden Clients zum Flaschenhals werden.
Mehrere tausend dedizierte Threads für entsprechend viele Clients zu betreiben, würde zwar funktionieren, ist aber im Gesamtbetrieb ineffizient und schwer zu managen. Jetrelay löst dieses Problem durch den Einsatz von io_uring, einer modernen Linux-Technologie für asynchrone E/A-Operationen. Damit können viele sendfile-ähnliche Übertragungen parallel vorbereitet, an den Kernel übergeben und dann deren Abschluss im effizienten Polling-Verfahren abgefragt werden. Dieser Mechanismus reduziert deutlich die Anzahl der notwendigen Systemaufrufe und sorgt dafür, dass die Hauptlogik des Relays schlank und performant bleibt, egal wie viele Clients verbunden sind. Interessanterweise existiert für io_uring keine direkte sendfile-Operation.
Jetrelay emuliert den Vorgang daher mit einer Kombination aus zwei splice()-Operationen, die nacheinander auf einer speziell pro Client angelegten Pipe ausgeführt werden. Das Ergebnis ist gleichwertig, aber mit io_uring im Hintergrund hervorragend skalierbar und wartbar. Die Integration dieser fortschrittlichen Linux-Funktionalitäten macht einen Großteil der Performance aus, die Jetrelay im Vergleich zu anderen Implementierungen auszeichnet. Neben der Datenverteilung spielt auch der Verbindungsaufbau eine wichtige Rolle. Eingehende Clients können ihren Startpunkt im Feed mit einem Zeitstempel definieren, um verpasste Ereignisse nachholen zu können.
Um diese Anfragen effizient zu bedienen, führt Jetrelay einen Index in Form eines B-Baums, der für jeden Zeitstempel die entsprechende Byteposition im Datenfile kennt. Dieser Index entsteht im Hintergrund und wird synchron zum Schreiben der Events gepflegt. Dank des mutex-geschützten Zugriffs kann er ohne komplexe Synchronisierung zwischen Schreib- und Leser-Threads genutzt werden. Neue Clients erhalten so nach dem Handshake sofort den passenden Cursor gesetzt und können nahtlos in den Stream eingebunden werden. Eine weitere technische Meisterleistung von Jetrelay ist die Möglichkeit, alte, nicht mehr benötigte Daten im Eventfile sicher und ohne Komplikationen zu entfernen.
Die Datei wächst theoretisch mit jedem neuen Ereignis an, was langfristig natürlich zum Problem einer unbegrenzten Dateigröße und damit zu Speicherengpässen führen könnte. Statt zur klassischen Logrotation zu greifen, die potenziell zu komplizierter Synchronisation und Cursor-Fehlern führen kann, verwendet Jetrelay den Linux-Systemaufruf fallocate() mit dem Parameter zum „Punch Hole“. Dadurch können frühe Bereiche der Datei deallokiert, also quasi unsichtbar gemacht werden, ohne ihre Position zu verändern. Für die Anwendung sieht die Datei zwar nach außen hin weiter größer aus, belegt auf dem Datenträger aber nur den tatsächlich genutzten, aktuellen Bereich. Solange keine Clients auf die gelochten Bereiche zugreifen, bleibt das System konsistent und performant.
Ein kleiner Haken bleibt: Clients, die zu langsam sind und noch auf alte, mittlerweile deallokierte Bereiche blicken, müssen vom Relay getrennt werden, um fehlerhafte Datenübertragungen zu verhindern. Aber auch hier ist der Aufwand gering und lässt sich automatisiert handhaben. So garantiert Jetrelay eine stabile Datenhaltung und kurzfristige Bereinigung ohne Performanceeinbußen. Nicht zuletzt hat sich Jetrelay auch im Praxisbetrieb bewiesen. Sowohl unter lokalen Testbedingungen auf einem Laptop als auch im realen Einsatz auf einem virtuellen Server mit einer 10-Gigabit-Netzwerkschnittstelle bewältigte das Relay tausende von Clientverbindungen parallel.
Dabei konnte es sämtliche angeschlossenen Clients zuverlässig mit den aktuellen Ereignissen versorgen und eine Durchsatzrate erzielen, die den verfügbaren Netzwerkkanal vollständig ausnutzte. Selbst mit 8000 oder 9000 Clients hielt das System stabil durch, bevor hardwarebedingte Limits zum Tragen kamen. Beeindruckend ist auch, dass diese Leistung bereits mit einer vergleichsweise geringen Anzahl an CPU-Kernen, etwa 8, erreicht wurde, was auf eine sehr effiziente Ressourcennutzung hinweist. Ein Vergleich mit dem offiziellen Jetstream-Server zeigt zudem die Vorteile der Jetrelay-Architektur deutlich. Das offizielle Relay, das eine komplexere Event-Verarbeitung und Filtermöglichkeiten bietet, erreicht im Test bei weitem nicht dieselben Übertragungsraten und erfordert oft aufwendigere Ressourcenmanagement.
Jetrelay hingegen verzichtet bewusst auf umfangreiche Features wie Filter, trägt aber durch diese Fokussierung ein Höchstmaß an Geschwindigkeit und Stabilität bei der einfachen Weiterleitung kompletter Feeds bei. Die Idee, Systemaufrufe und Kernel-Möglichkeiten maximal auszunutzen und den Userspace so wenig wie möglich zu belasten, erweist sich hier als durchdachtes Konzept für moderne, hochskalierbare Pub/Sub-Architekturen. Jetrelay zeigt, wie effektives Systemdesign mit schlankem Code und moderner Linux-Technik wettbewerbsfähige Software ermöglichen kann, die den hohen Anforderungen heutiger Echtzeit-Datenverteilung gewachsen ist. Wer an der Technik interessiert ist, findet den Quellcode von Jetrelay offen zugänglich und ist eingeladen, Ideen, Verbesserungen oder spezifische Anpassungen einzubringen. Ob im produktiven Einsatz oder als Experimentierplattform für zukünftige Pub/Sub-Protokolle – Jetrelay bietet eine inspirierende Basis mit klarem Fokus auf Performanz und Skalierbarkeit.
Insgesamt ist Jetrelay ein überzeugendes Beispiel dafür, dass trotz technologischer Komplexität und wachsender Datenströme kreative und elegante Lösungen zu finden sind, die mit vergleichsweise geringem Aufwand hohe Leistungsstandards setzen. Für Betreiber und Entwickler von datenintensiven Streaming-Anwendungen ist es deshalb lohnenswert, die Konzepte und Techniken hinter Jetrelay kennenzulernen und in der eigenen Infrastruktur zu prüfen.
