Warum wir die Echtzeit-Infrastruktur von Cliqer von Cloudflare weggeholt haben (und warum wir trotzdem Fans bleiben)

Am 24. September 2026 um 18:42 UTC haben wir jede Live-Verbindung von Cliqer von Cloudflare Workers und Durable Objects auf unsere eigenen dedizierten Server umgezogen. Wir haben es mit dem Edge versucht, und dieses Mal hat er uns im Stich gelassen. Wenn Sie Cliqer nutzen, ändert sich an Ihrer Arbeitsweise nichts. Was sich ändert, passiert darunter: Ihre Räume starten nicht mehr aus Gründen neu, die niemand erklären kann.

Dieser Beitrag ist die ehrliche Erklärung dafür. Er ist auch ein Dankeschön, denn wir sind weiterhin Cloudflare-Kunden und echte Fans dessen, was dort gebaut wird.

Was wir bauen wollten

Cliqer ist ein Live-Werkzeug. Ein Vortragender tippt auf sein Smartphone, und auf einem Bildschirm, der vielleicht auf einem anderen Kontinent steht, wechselt eine Folie. Anrufer treten einer Show bei, Hosts schalten Quellen um, Timer zählen auf der Bühne herunter. All das läuft über WebSockets: langlebige Verbindungen, die nicht flackern dürfen, denn wenn sie es tun, passiert es vor Publikum.

Durable Objects schienen perfekt zu passen. Jeder Raum bekommt ein Single-Threaded-Objekt, das seine eigenen Sockets und seinen eigenen Speicher hält und im Netzwerk von Cloudflare läuft. Keine Server zu verwalten, keine Skalierung zu planen. Ende Mai liefen alle Räume darauf, und im Juni kam die Legacy-Bridge von Cliqer v1 dazu.

Was schiefging

Neustarts, die wir nicht erklären konnten

Ein Durable Object kann von der Plattform jederzeit neu gestartet werden, und bei einem Neustart wird jeder WebSocket geschlossen, den es hält. In einem 24-Stunden-Zeitfenster von Logs haben wir gezielt danach gesucht: Kein einziger Socket überlebte einen Neustart. Nicht einer.

Das wäre in Ordnung, wenn Neustarts selten wären. Das waren sie nicht:

• 21 Neustarts in 5 Tagen beim Objekt in Lissabon, das alle Räume hielt, 4 davon in einer einzigen Stunde. Kein Out-of-Memory, kein CPU-Limit, eine Handvoll plattforminterner Fehler und kein Deploy von unserer Seite.
• Wir haben es verlegt. Durable Objects bleiben dort, wo sie zuerst erstellt werden, also bedeutet Verlegen, sie neu zu erstellen und zu hoffen, dass sie an einem besseren Ort landen. Der erste Versuch landete in Madrid, der nächste in Amsterdam.
• In Amsterdam gingen die Neustarts weiter, alle 2 bis 16 Stunden, im Schnitt etwa alle 8,7 Stunden.
• Im September startete das Objekt für Legacy-Räume immer noch 2 bis 5 Mal am Tag neu, ohne jeden Anlass. Am 8. September um 18:53 Uhr schlossen sich alle Legacy-Verbindungen innerhalb derselben Millisekunde. Kein Deploy, kein Vorfall auf der Statusseite.

Für Sie war jeder davon ein Moment, in dem der Presenter nicht mehr reagierte, ein Anrufer verschwand oder die App mitten in einer Show meldete, dass sie sich neu verbindet.

Speicher, der in ein Timeout lief und den Raum zurücksetzte

Zwischen dem 7. und 10. September sahen wir die Fehlermeldung „Durable Object storage operation exceeded timeout which caused object to be reset“ 8 Mal bei 4 Objekten. Ein Versuch, die Verbindung wiederherzustellen, wartete 44,5 Sekunden, bevor er fehlschlug. Ein Speicherzugriff, der Millisekunden dauern sollte, riss den ganzen Raum mit sich.

Jeder Deploy startete jeden Raum neu

Das ist dokumentiert, und das ist fair: Wird eine neue Version eines Workers ausgeliefert, starten seine Durable Objects neu, und ihr Neustart schließt ihre Verbindungen. Zwischen dem 19. und 21. August kamen 44 % der Reconnects in Live-Räumen von Kunden in synchronisierten Wellen, und drei unserer eigenen Releases an einem Tag trennten jeden Raum, eines davon mitten in einer Show.

Also haben wir die Sockets in einen eigenen Worker ausgelagert und ein Tool gebaut, das jede geänderte Datei prüfte und entschied, welche Deploys Räume berühren durften. Das funktionierte: Das nächste Website-Release ging mit fünf Live-Hosts und null Raum-Ereignissen raus. Es bedeutete aber auch, dass jede Änderung am Echtzeit-Code weiterhin alle neu startete.

Subtiles Verhalten, das uns in Live-Shows erwischte

• 16 Minuten Stille. Am 4. August blieben 43 Sockets verbunden, während an keinen einzigen Raum Nachrichten zugestellt wurden. Der Edge beantwortete weiterhin Heartbeats im Namen des Raums, also wusste kein Client, dass etwas nicht stimmte, und niemand verband sich neu. Ursache war eine Plattformfunktion, die wir gerade eingeführt hatten, in Kombination mit unserer eigenen Buchführung. Wir haben sie noch in derselben Woche zurückgenommen.
• Geister-Hosts. Close-Events erreichen ein schlafendes Objekt nicht garantiert, sodass ein Host, der längst gegangen war, stundenlang verbunden wirken konnte.
• Eine gecachte URL, vier Stunden lang festgefahren. Im August blieb eine Caching-Schicht vor unserem Worker an genau der URL hängen, die die Desktop-App beim Start prüft. Die App konnte nicht starten. Dieselbe URL mit einem Unsinnsparameter antwortete innerhalb einer Sekunde.

Was wir als Workaround gebaut haben

In diesen vier Monaten haben wir rund 18 separate Mechanismen gebaut, um die Plattform vor Ihnen zu verbergen: schnellere Heartbeats, Aufräumläufe für Geister-Hosts, Registries, die bei jedem Aufwachen aus dem Speicher neu aufgebaut werden, Identitäten, die einen Neustart überstehen, damit Ihre Apps weitermachen können, einen separaten Socket-Worker, einen Deploy-Klassifikator für 161 Dateien, neu ausgewürfelte Platzierungen, einen Relay-Watchdog, Sharding pro Raum und dazu ein shardübergreifendes Platz-Register.

Drei davon haben wir später wieder gelöscht, weil sie mehr Probleme verursachten als lösten. Und jeder Workaround fügte bewegliche Teile hinzu. Das Aufteilen von Räumen auf mehrere Objekte bescherte uns einen abtrünnigen Raum, der für den falschen Shard antwortete, einen Zuschauer, der in einer Umzugsschleife feststeckte, und ein Platzlimit, das sich über Shards hinweg umgehen ließ. Alles wurde behoben, aber wir verbrachten unsere Zeit damit, um die Plattform herum zu entwickeln, statt Cliqer weiterzuentwickeln.

Fair bleiben

Nicht jeder Verbindungsabbruch in diesen Monaten ging auf Cloudflare zurück. Wir haben nachgesehen:

• 86 % der einzelnen Reconnects betrafen einzelne Geräte, die von ihrem eigenen Netzwerk getrennt wurden: Unternehmens-Proxys, WLAN am Veranstaltungsort, Firewalls, die lange Verbindungen nicht mögen. Deshalb haben wir im August Unterstützung für Unternehmensnetzwerke in die Desktop-App gebracht.
• Einige Wellen waren unsere eigenen Deploys, und ein paar wurden durch unsere eigenen Debugging-Tools verursacht.
• Wir haben wegen der Neustarts nie ein Support-Ticket eröffnet. Das geht auf unsere Kappe.

Durable Objects sind ein brillantes Stück Technik, und für viele Workloads sind sie genau richtig. Ein Raum, der vor Live-Publikum niemals flackern darf, erwies sich als der schlimmste Fall für eine Plattform, die ihn jederzeit neu starten kann. Wir haben den Edge für Echtzeit ausprobiert, und dieses Mal hat er uns im Stich gelassen. Das ist ein Urteil über diesen Workload, nicht über den Edge.

Was Ihre Räume jetzt betreibt

Die Echtzeit-Infrastruktur von Cliqer läuft jetzt auf unseren eigenen dedizierten Servern. Sie liefern die Website, die API und jeden WebSocket aus und halten jeden Raum direkt, gestützt auf eine lokale Datenbank. Der Traffic läuft weiterhin über das Netzwerk von Cloudflare, Sie behalten also denselben Schutz und dieselben Adressen.

Was weggefallen ist:

• Keine Neustarts unter uns. Der Prozess läuft, bis wir etwas anderes entscheiden.
• Keine Platzierungslotterie und keine Speicher-Timeouts, die Räume zurücksetzen.
• Kein Sharding. Ein Raum, ein Ort, eine einzige verlässliche Datenquelle.

Wo wir ehrlich bleiben:

• Wenn wir ein Update ausliefern, wird Ihre Verbindung einmal neu aufgebaut. Die neue Version startet neben der alten und übernimmt fast sofort. Ihre Apps verbinden sich in etwa einer Sekunde mit derselben Identität neu und machen dort weiter, wo sie waren. In unserem Probelauf liefen 4.757 Web-Anfragen durch die Umschaltung, und keine schlug fehl.
• Unsere Server stehen in Europa. Wir betreiben lieber Maschinen, die wir vollständig verstehen, als Hunderte Standorte, in die wir nicht hineinsehen können.

Auch schneller

Wir protokollieren auf unserer Seite, wie lange jede API-Anfrage dauert, und können so die Woche vor dem Umzug mit den Tagen danach vergleichen, mit echtem Traffic statt mit einem Labortest.

Die langsamsten Anfragen haben sich sogar noch stärker verbessert. Das langsamste Zehntel der Branding-Ladevorgänge im Dashboard sank von 1,7 Sekunden auf unter eine halbe Sekunde, und die langsamsten Abrufe von Relay-Zugangsdaten wurden 7-mal schneller.

Die größte Veränderung spüren Sie zuerst. Eine Echtzeitverbindung, die auf der alten Plattform inaktiv gewesen war, brauchte etwa 1,2 Sekunden zum Öffnen, während sie aufwachte. Auf unserem eigenen Server öffnet sie sich in etwa 0,14 Sekunden, jedes Mal. Unser unabhängiger Uptime-Monitor, der cliqer.io jede Minute aus Nordamerika prüft, bestätigt das: etwa 750 ms pro Prüfung vor dem Umzug, etwa 380 ms danach.

Innerhalb eines Raums waren Klicks bereits schnell, und das sind sie weiterhin. Verändert hat sich alles drumherum: das Öffnen der App, das Laden der Seite für Vortragende, das Abrufen Ihres Kontos. Alles antwortet schneller, und jedes Mal gleich.

Was Cloudflare weiterhin für uns tut

Eine Menge, und das gern:

Ihre Observability- und Analysewerkzeuge haben auch den Großteil der Diagnose in diesem Beitrag erst möglich gemacht. Wir sind weiterhin Kunden und empfehlen Cloudflare weiterhin.

Wenn etwas abbricht, sagen Sie es uns

Unser Versprechen ist einfach: Wenn jetzt eine Verbindung abbricht, gibt es einen Grund, den wir finden können. Falls Sie jemals sehen, dass sich Cliqer mitten in einer Show neu verbindet (und hier steht, was zu tun ist, wenn Folien einfrieren, wenn es passiert), antworten Sie auf eine unserer E-Mails oder öffnen Sie einen Chat in der App. Wir lesen jede Nachricht, und jetzt können wir Ihnen tatsächlich sagen, warum.