Perché abbiamo tolto il realtime di Cliqer da Cloudflare (e perché ne restiamo fan)

Il 24 settembre 2026 alle 18:42 UTC abbiamo spostato ogni connessione live di Cliqer da Cloudflare Workers e Durable Objects ai nostri server dedicati. Abbiamo provato l'edge e, in questa occasione, ci ha delusi. Se usi Cliqer, nel tuo modo di lavorare non cambia nulla. Cambia ciò che succede sotto: le tue stanze non si riavviano più per motivi che nessuno sa spiegare.

Questo articolo è la versione onesta del perché. È anche un ringraziamento, perché siamo ancora clienti di Cloudflare e sinceri fan di ciò che costruiscono.

Cosa stavamo cercando di costruire

Cliqer è uno strumento live. Un relatore tocca il telefono e una slide avanza su uno schermo che potrebbe trovarsi in un altro continente. Gli ospiti si collegano a uno show, gli host cambiano sorgente, i timer scorrono sul palco. Tutto questo viaggia su WebSocket: connessioni di lunga durata che non devono avere il minimo cedimento, perché quando succede, accade davanti al pubblico.

Durable Objects sembrava la soluzione perfetta. Ogni stanza ha un oggetto a thread singolo che gestisce i propri socket e il proprio storage, in esecuzione sulla rete di Cloudflare. Nessun server da gestire, nessuna scalabilità da pianificare. A fine maggio tutte le stanze giravano lì, e a giugno si è aggiunto anche il bridge legacy di Cliqer v1.

Cosa è andato storto

Riavvii che non riuscivamo a spiegare

Un Durable Object può essere riavviato dalla piattaforma in qualsiasi momento e, quando si riavvia, ogni WebSocket che gestisce viene chiuso. In una finestra di 24 ore di log, controllata appositamente per questo: nessun socket è sopravvissuto a un riavvio. Nemmeno uno.

Non sarebbe stato un problema se i riavvii fossero stati rari. Non lo erano:

• 21 riavvii in 5 giorni per l'oggetto di Lisbona che ospitava tutte le stanze, 4 dei quali in una sola ora. Nessun esaurimento di memoria, nessun limite di CPU, una manciata di errori interni alla piattaforma e nessun deploy da parte nostra.
• Lo abbiamo spostato. I Durable Objects restano dove vengono creati la prima volta, quindi spostarli significa ricrearli e sperare che finiscano in un posto migliore. Il primo tentativo è finito a Madrid, il successivo ad Amsterdam.
• Ad Amsterdam i riavvii sono continuati, ogni da 2 a 16 ore, in media circa ogni 8,7 ore.
• A settembre, l'oggetto che serviva le stanze legacy si riavviava ancora da 2 a 5 volte al giorno, senza alcun motivo. L'8 settembre alle 18:53 tutte le connessioni legacy si sono chiuse nello stesso millisecondo. Nessun deploy, nessun incidente sulla pagina di stato.

Per te, ognuno di questi episodi è stato un momento in cui il telecomando per presentazioni smetteva di rispondere, un ospite in collegamento spariva o l'app segnalava una riconnessione nel bel mezzo di uno show.

Storage che andava in timeout e resettava la stanza

Tra il 7 e il 10 settembre abbiamo visto il messaggio di errore «Durable Object storage operation exceeded timeout which caused object to be reset» 8 volte su 4 oggetti. Un tentativo di riconnessione ha atteso 44,5 secondi prima di fallire. Una lettura dallo storage che avrebbe dovuto richiedere millisecondi si è portata dietro l'intera stanza.

Ogni deploy riavviava tutte le stanze

Questo è documentato, ed è giusto così: pubblicare una nuova versione di un Worker riavvia i suoi Durable Objects, e riavviarli chiude le loro connessioni. Tra il 19 e il 21 agosto, il 44% delle riconnessioni nelle stanze live dei clienti è arrivato a ondate sincronizzate, e tre nostri rilasci in un solo giorno hanno fatto cadere tutte le stanze, uno dei quali in pieno show.

Così abbiamo spostato i socket in un Worker dedicato e creato uno strumento che esaminava ogni file modificato e decideva quali deploy potevano toccare le stanze. Ha funzionato: il rilascio successivo del sito è andato online con cinque host live e zero eventi nelle stanze. Ma significava anche che qualsiasi modifica al codice realtime riavviava ancora tutti.

Comportamenti sottili che ci hanno colpito durante gli show live

• 16 minuti di silenzio. Il 4 agosto, 43 socket sono rimasti connessi mentre nessun messaggio veniva consegnato ad alcuna stanza. L'edge continuava a rispondere agli heartbeat al posto della stanza, quindi nessun client si accorgeva che qualcosa non andava e nessuno si riconnetteva. Il problema nasceva da una funzione della piattaforma appena adottata, combinata con la nostra logica di gestione interna. L'abbiamo annullata la settimana stessa.
• Host fantasma. Non è garantito che gli eventi di chiusura raggiungano un oggetto inattivo, quindi un host che se n'era andato poteva risultare connesso per ore.
• Un URL in cache bloccato per quattro ore. Ad agosto, un livello di cache davanti al nostro Worker si è bloccato proprio sull'URL che l'app desktop controlla all'avvio. L'app non riusciva ad avviarsi. Lo stesso URL con un parametro fittizio rispondeva in un secondo.

Cosa abbiamo costruito per farvi fronte

In quei quattro mesi abbiamo costruito circa 18 meccanismi separati per nasconderti la piattaforma: heartbeat più frequenti, pulizie periodiche degli host fantasma, registri ricostruiti dallo storage a ogni risveglio, identità che sopravvivono a un riavvio così che le tue app possano riprendere, un Worker separato per i socket, un classificatore dei deploy che copriva 161 file, ricollocazioni ripetute, un watchdog per i relay, lo sharding per stanza e, insieme, un registro dei posti condiviso tra gli shard.

Tre di questi li abbiamo poi eliminati, perché causavano più problemi di quanti ne risolvessero. E ogni soluzione di ripiego aggiungeva parti in movimento. Suddividere le stanze tra più oggetti ci ha regalato una stanza ribelle che rispondeva per lo shard sbagliato, uno spettatore bloccato in un ciclo di ricollocazione e un limite di posti aggirabile tra gli shard. Abbiamo risolto ogni problema, ma passavamo il tempo a progettare soluzioni per aggirare la piattaforma invece di sviluppare Cliqer.

Per essere onesti

Non tutte le connessioni cadute in quei mesi erano colpa di Cloudflare. Lo abbiamo verificato:

• L'86% delle singole riconnessioni riguardava singoli dispositivi disconnessi dalla propria rete: proxy aziendali, Wi-Fi delle location, firewall che non amano le connessioni lunghe. Ecco perché ad agosto abbiamo introdotto nell'app desktop il supporto per le reti aziendali.
• Alcune ondate erano dovute ai nostri deploy, e qualcuna ai nostri stessi strumenti di debug.
• Non abbiamo mai aperto un ticket di supporto per i riavvii. Questa è colpa nostra.

I Durable Objects sono un brillante lavoro di ingegneria e, per molti carichi di lavoro, sono esattamente la scelta giusta. Una stanza che non deve mai avere il minimo cedimento, davanti a un pubblico dal vivo, si è rivelata il caso peggiore per una piattaforma che può riavviarla in qualsiasi momento. Abbiamo provato l'edge per il realtime e, in questa occasione, ci ha delusi. È un giudizio su questo carico di lavoro, non sull'edge.

Cosa gestisce le tue stanze oggi

Il realtime di Cliqer ora gira sui nostri server dedicati. Servono il sito, l'API e ogni WebSocket, e ospitano direttamente ogni stanza, con il supporto di un database locale. Il traffico passa ancora attraverso la rete di Cloudflare, quindi mantieni la stessa protezione e gli stessi indirizzi.

Cosa è sparito:

• Nessun riavvio a nostra insaputa. Il processo resta attivo finché non decidiamo diversamente.
• Nessuna lotteria del posizionamento e nessun timeout dello storage che resetta le stanze.
• Nessuno sharding. Una stanza, un luogo, un'unica fonte di verità.

Dove restiamo trasparenti:

• Quando pubblichiamo un aggiornamento, la tua connessione si riconnette una volta. La nuova versione parte accanto alla vecchia e subentra quasi istantaneamente. Le tue app si riconnettono in circa un secondo con la stessa identità e riprendono da dove erano. Nella nostra prova generale, 4.757 richieste web sono passate attraverso il cambio e nessuna è fallita.
• I nostri server sono in Europa. Preferiamo gestire macchine che comprendiamo a fondo piuttosto che centinaia di luoghi in cui non possiamo guardare dentro.

Anche più veloce

Registriamo la durata di ogni richiesta API dal nostro lato, quindi possiamo confrontare la settimana prima del trasferimento con i giorni successivi, usando traffico reale e non un test di laboratorio.

Le richieste più lente sono migliorate ancora di più. Il 10% più lento dei caricamenti del branding della dashboard è sceso da 1,7 secondi a meno di mezzo secondo, e i recuperi più lenti delle credenziali relay sono diventati 7 volte più veloci.

Il cambiamento più grande è quello che si percepisce per primo. Una connessione realtime rimasta inattiva sulla vecchia piattaforma impiegava circa 1,2 secondi ad aprirsi, il tempo di risvegliarsi. Sul nostro server si apre in circa 0,14 secondi, ogni volta. Il nostro monitor di uptime indipendente, che controlla cliqer.io ogni minuto dal Nord America, racconta la stessa storia: circa 750 ms per controllo prima del trasferimento, circa 380 ms dopo.

All'interno di una stanza, i clic erano già rapidi e lo sono ancora. Ciò che è cambiato è tutto ciò che sta intorno: aprire l'app, caricare la pagina del relatore, recuperare il tuo account. Tutto risponde più velocemente, e allo stesso modo ogni volta.

Cosa fa ancora Cloudflare per noi

Molto, e con piacere:

Anche i loro strumenti di osservabilità e analisi hanno reso possibile gran parte della diagnosi descritta in questo articolo. Siamo ancora clienti e continuiamo a consigliarli.

Se qualcosa cade, diccelo

La nostra promessa è semplice: quando ora una connessione cade, c'è un motivo che possiamo trovare. Se mai vedi Cliqer riconnettersi durante uno show (ed ecco cosa fare quando le slide si bloccano sul momento), rispondi a una qualsiasi delle nostre email o apri una chat dall'app. Le leggiamo tutte, e ora possiamo davvero dirti il perché.