Waarom we de realtime van Cliqer bij Cloudflare weghaalden (en waarom we nog steeds fan zijn)

Op 24 september 2026 om 18:42 UTC hebben we elke live Cliqer-verbinding van Cloudflare Workers en Durable Objects verhuisd naar onze eigen dedicated servers. We hebben de edge geprobeerd, en deze keer liet die ons in de steek. Gebruik je Cliqer, dan verandert er niets aan hoe je werkt. Wat verandert, is wat er onder de motorkap gebeurt: je ruimtes herstarten niet meer om redenen die niemand kan verklaren.

Deze post is de eerlijke versie van het waarom. Het is ook een bedankje, want we zijn nog steeds klant bij Cloudflare en nog steeds oprecht fan van wat ze bouwen.

Wat we probeerden te bouwen

Cliqer is een live tool. Een presentator tikt op zijn telefoon en er schuift een dia door op een scherm dat misschien op een ander continent staat. Bellers sluiten aan bij een show, hosts schakelen tussen bronnen, timers tellen af op het podium. Dat alles loopt via WebSockets: langdurige verbindingen die geen moment mogen haperen, want als dat gebeurt, gebeurt het voor een publiek.

Durable Objects leken perfect te passen. Elke ruimte krijgt een single-threaded object dat zijn eigen sockets en zijn eigen opslag beheert en op het netwerk van Cloudflare draait. Geen servers om te beheren, geen schaalvergroting om te plannen. Eind mei draaide elke ruimte erop, en in juni sloot de oude Cliqer v1-bridge zich aan.

Wat er misging

Herstarts die we niet konden verklaren

Een Durable Object kan op elk moment door het platform worden herstart, en bij een herstart wordt elke WebSocket die het vasthoudt gesloten. In één logvenster van 24 uur hebben we hier specifiek op gecontroleerd: geen enkele socket overleefde een herstart. Niet één.

Dat zou geen probleem zijn als herstarts zeldzaam waren. Dat waren ze niet:

• 21 herstarts in 5 dagen voor het object in Lissabon dat elke ruimte beheerde, waarvan 4 in één uur. Geen out-of-memory, geen CPU-limiet, een handvol platforminterne fouten en geen deploy van onze kant.
• We hebben het verplaatst. Durable Objects blijven waar ze voor het eerst zijn aangemaakt, dus verplaatsen betekent opnieuw aanmaken en hopen dat het ergens beter terechtkomt. De eerste poging belandde in Madrid, de volgende in Amsterdam.
• In Amsterdam bleven de herstarts komen, elke 2 tot 16 uur, gemiddeld ongeveer elke 8,7 uur.
• In september herstartte het object voor de legacy-ruimtes nog steeds 2 tot 5 keer per dag, uit zichzelf. Op 8 september om 18:53 werden alle legacy-verbindingen binnen dezelfde milliseconde gesloten. Geen deploy, geen incident op de statuspagina.

Voor jou was elk daarvan een moment waarop de presentatieclicker niet meer reageerde, een beller verdween of de app midden in een show meldde dat hij opnieuw verbinding maakte.

Opslag die een time-out gaf en de ruimte resette

Tussen 7 en 10 september zagen we de foutmelding "Durable Object storage operation exceeded timeout which caused object to be reset" 8 keer verspreid over 4 objecten. Eén poging om opnieuw te verbinden wachtte 44,5 seconden voordat die mislukte. Een leesactie uit de opslag die milliseconden zou moeten duren, sleepte de hele ruimte mee onderuit.

Elke deploy herstartte elke ruimte

Deze is gedocumenteerd, en dat is terecht: een nieuwe versie van een Worker uitrollen herstart de bijbehorende Durable Objects, en die herstarten sluit hun verbindingen. Tussen 19 en 21 augustus kwam 44% van de herverbindingen in live klantruimtes in gesynchroniseerde golven, en drie van onze eigen releases op één dag lieten elke ruimte wegvallen, één ervan midden in een show.

Dus splitsten we de sockets af naar een eigen Worker en bouwden we een tool die elk gewijzigd bestand bekeek en besliste welke deploys aan ruimtes mochten komen. Dat werkte: de volgende websiterelease ging live met vijf live hosts en nul ruimte-events. Het betekende ook dat elke wijziging aan de realtime-code nog steeds iedereen herstartte.

Subtiel gedrag dat ons opbrak tijdens live shows

• 16 minuten stilte. Op 4 augustus bleven 43 sockets verbonden terwijl er nul berichten bij welke ruimte dan ook aankwamen. De edge bleef namens de ruimte heartbeats beantwoorden, dus geen enkele client wist dat er iets mis was en niemand maakte opnieuw verbinding. Dit kwam door een platformfunctie die we net in gebruik hadden genomen, in combinatie met onze eigen administratie. We hebben het dezelfde week teruggedraaid.
• Spookhosts. Close-events komen niet gegarandeerd aan bij een slapend object, waardoor een host die al weg was urenlang verbonden kon lijken.
• Een gecachte URL die vier uur vastzat. In augustus bleef een cachinglaag voor onze Worker hangen op de enige URL die de desktop-app bij het opstarten controleert. De app kon niet opstarten. Dezelfde URL met een willekeurige parameter antwoordde binnen een seconde.

Wat we bouwden om ermee om te gaan

In die vier maanden bouwden we zo'n 18 afzonderlijke mechanismen om het platform voor jou te verbergen: snellere heartbeats, opschoonrondes voor spookhosts, registers die bij elke wake opnieuw uit de opslag werden opgebouwd, identiteiten die een herstart overleven zodat je apps verder kunnen gaan, een aparte socket-Worker, een deploy-classifier voor 161 bestanden, opnieuw gegooide plaatsingen, een relay-watchdog, sharding per ruimte en een bijbehorend stoelenregister over shards heen.

Drie daarvan hebben we later verwijderd omdat ze meer problemen veroorzaakten dan ze oplosten. En elke workaround voegde bewegende onderdelen toe. Ruimtes over objecten sharden leverde ons een losgeslagen ruimte op die voor de verkeerde shard antwoordde, een kijker die vastzat in een verplaatsingslus en een stoelenlimiet die over shards heen te omzeilen was. Alles werd opgelost, maar we waren onze tijd kwijt aan engineeren rond het platform in plaats van aan het bouwen van Cliqer.

Eerlijk blijven

Niet elke weggevallen verbinding in die maanden lag aan Cloudflare. We hebben het gecontroleerd:

• 86% van de individuele herverbindingen betrof losse apparaten die door hun eigen netwerk werden afgesloten: bedrijfsproxy's, wifi op locatie, firewalls die niet van lange verbindingen houden. Daarom brachten we in augustus ondersteuning voor bedrijfsnetwerken uit in de desktop-app.
• Sommige golven kwamen door onze eigen deploys, en een paar door onze eigen debugtools.
• We hebben nooit een supportticket over de herstarts aangemaakt. Dat is onze fout.

Durable Objects zijn een briljant staaltje engineering en voor veel workloads precies goed. Een ruimte die nooit mag haperen, voor een live publiek, bleek het slechtst denkbare scenario voor een platform dat hem op elk moment kan herstarten. We hebben de edge geprobeerd voor realtime, en deze keer liet die ons in de steek. Dat is een oordeel over deze workload, niet over de edge.

Waar je ruimtes nu op draaien

De realtime van Cliqer draait nu op onze eigen dedicated servers. Die bedienen de website, de API en elke WebSocket, en houden elke ruimte direct vast, ondersteund door een lokale database. Het verkeer loopt nog steeds via het netwerk van Cloudflare, dus je houdt dezelfde bescherming en dezelfde adressen.

Wat er verdwenen is:

• Geen herstarts onder ons vandaan. Het proces draait tot wij anders besluiten.
• Geen plaatsingsloterij en geen opslag-time-outs die ruimtes resetten.
• Geen sharding. Eén ruimte, één plek, één bron van waarheid.

Waar we eerlijk over blijven:

• Als we een update uitrollen, wordt je verbinding één keer opnieuw opgebouwd. De nieuwe versie start naast de oude en neemt vrijwel direct over. Je apps maken in ongeveer een seconde opnieuw verbinding met dezelfde identiteit en gaan verder waar ze waren. In onze generale repetitie gingen 4.757 webverzoeken door de overschakeling en mislukte er geen enkele.
• Onze servers staan in Europa. We draaien liever machines die we volledig begrijpen dan honderden locaties waar we niet in kunnen kijken.

Ook sneller

We loggen aan onze kant hoe lang elk API-verzoek duurt, zodat we de week voor de verhuizing kunnen vergelijken met de dagen erna, met echt verkeer in plaats van een labtest.

De traagste verzoeken verbeterden nog meer. De traagste tien procent van het laden van dashboardbranding daalde van 1,7 seconden naar minder dan een halve seconde, en de traagste ophaalacties van relay-inloggegevens werden 7 keer sneller.

De grootste verandering is de verandering die je als eerste merkt. Een realtime-verbinding die op het oude platform inactief was geweest, had ongeveer 1,2 seconden nodig om te openen terwijl hij wakker werd. Op onze eigen server opent hij in ongeveer 0,14 seconden, elke keer weer. Onze onafhankelijke uptimemonitor, die cliqer.io elke minuut vanuit Noord-Amerika controleert, vertelt hetzelfde verhaal: ongeveer 750 ms per check voor de verhuizing, ongeveer 380 ms erna.

Binnen een ruimte waren klikken al snel en dat zijn ze nog steeds. Wat veranderde, is alles eromheen: de app openen, de presentatorpagina laden, je account ophalen. Alles antwoordt sneller, en elke keer op dezelfde manier.

Wat Cloudflare nog steeds voor ons doet

Veel, en met plezier:

Hun observability en analytics maakten ook het grootste deel van de diagnose in deze post mogelijk. We zijn nog steeds klant en we raden ze nog steeds aan.

Valt er iets weg? Laat het ons weten

Onze belofte is eenvoudig: als een verbinding nu wegvalt, is er een reden die we kunnen vinden. Zie je Cliqer ooit midden in een show opnieuw verbinden (en hier lees je wat je moet doen als dia's bevriezen op dat moment), reageer dan op een van onze e-mails of open een chat vanuit de app. We lezen ze allemaal, en nu kunnen we je ook echt vertellen waarom.