Por qué sacamos el tiempo real de Cliqer de Cloudflare (y por qué seguimos siendo fans)

El 24 de septiembre de 2026 a las 18:42 UTC trasladamos todas las conexiones en directo de Cliqer de Cloudflare Workers y Durable Objects a nuestros propios servidores dedicados. Probamos el edge y, en esta ocasión, nos falló. Si usas Cliqer, no cambia nada en tu forma de trabajar. Lo que cambia es lo que ocurre por debajo: tus salas ya no se reinician por motivos que nadie sabe explicar.

Este artículo es la versión honesta del porqué. También es un agradecimiento, porque seguimos siendo clientes de Cloudflare y seguimos siendo auténticos fans de lo que construyen.

Qué intentábamos construir

Cliqer es una herramienta para el directo. Un presentador toca su teléfono y una diapositiva avanza en una pantalla que puede estar en otro continente. Los invitados se unen a un programa, los anfitriones cambian de fuente, los temporizadores cuentan hacia atrás en el escenario. Todo eso se apoya en WebSockets: conexiones de larga duración que no pueden parpadear, porque cuando lo hacen, ocurre delante del público.

Durable Objects parecía encajar a la perfección. Cada sala obtiene un objeto de un solo hilo que mantiene sus propios sockets y su propio almacenamiento, ejecutándose en la red de Cloudflare. Sin servidores que gestionar, sin escalado que planificar. A finales de mayo todas las salas funcionaban sobre ellos, y el puente heredado de Cliqer v1 se sumó en junio.

Qué salió mal

Reinicios que no podíamos explicar

La plataforma puede reiniciar un Durable Object en cualquier momento y, cuando se reinicia, se cierran todos los WebSockets que mantiene. En una ventana de 24 horas de registros comprobamos específicamente esto: ningún socket sobrevivió a un reinicio. Ni uno.

Eso no sería un problema si los reinicios fueran raros. No lo eran:

• 21 reinicios en 5 días del objeto de Lisboa que alojaba todas las salas, 4 de ellos en una sola hora. Sin falta de memoria, sin límite de CPU, un puñado de errores internos de la plataforma y ningún despliegue por nuestra parte.
• Lo trasladamos. Los Durable Objects se quedan donde se crean por primera vez, así que trasladarlo significa recrearlo y esperar que acabe en un sitio mejor. El primer intento acabó en Madrid; el siguiente, en Ámsterdam.
• En Ámsterdam los reinicios siguieron llegando, cada 2 a 16 horas, aproximadamente cada 8,7 horas de media.
• En septiembre, el objeto que servía las salas heredadas seguía reiniciándose de 2 a 5 veces al día, sin motivo aparente. El 8 de septiembre a las 18:53, todas las conexiones heredadas se cerraron en el mismo milisegundo. Sin despliegue, sin incidencias en la página de estado.

Para ti, cada uno de esos reinicios fue un momento en el que el control remoto para presentaciones dejó de responder, un invitado desapareció o la app avisaba de que se estaba reconectando en pleno directo.

Almacenamiento que agotaba el tiempo de espera y reseteaba la sala

Entre el 7 y el 10 de septiembre vimos el mensaje de error «Durable Object storage operation exceeded timeout which caused object to be reset» 8 veces en 4 objetos. Un intento de reconexión esperó 44,5 segundos antes de fallar. Una lectura de almacenamiento que debería tardar milisegundos tumbó la sala entera.

Cada despliegue reiniciaba todas las salas

Esto está documentado, y es justo: publicar una nueva versión de un Worker reinicia sus Durable Objects, y reiniciarlos cierra sus conexiones. Entre el 19 y el 21 de agosto, el 44 % de las reconexiones en salas de clientes en directo llegó en oleadas sincronizadas, y tres de nuestras propias versiones en un mismo día tumbaron todas las salas, una de ellas en pleno directo.

Así que separamos los sockets en su propio Worker y creamos una herramienta que revisaba cada archivo modificado y decidía qué despliegues podían tocar las salas. Funcionó: la siguiente versión de la web salió con cinco anfitriones en directo y cero eventos en las salas. Pero también implicaba que cualquier cambio en el código de tiempo real seguía reiniciando a todo el mundo.

Comportamientos sutiles que nos pasaron factura en directo

• 16 minutos de silencio. El 4 de agosto, 43 sockets siguieron conectados mientras no se entregaba ni un solo mensaje a ninguna sala. El edge seguía respondiendo a los heartbeats en nombre de la sala, así que ningún cliente sabía que algo iba mal y nadie se reconectó. Esto vino de una función de la plataforma que acabábamos de adoptar, combinada con nuestra propia contabilidad interna. La revertimos esa misma semana.
• Anfitriones fantasma. No está garantizado que los eventos de cierre lleguen a un objeto dormido, así que un anfitrión que se había ido podía aparecer como conectado durante horas.
• Una URL en caché atascada durante cuatro horas. En agosto, una capa de caché delante de nuestro Worker se quedó atascada en la única URL que la app de escritorio comprueba al arrancar. La app no podía iniciarse. La misma URL con un parámetro basura respondía en un segundo.

Qué construimos para sobrellevarlo

A lo largo de esos cuatro meses construimos unos 18 mecanismos distintos para ocultarte la plataforma: heartbeats más rápidos, barridos de anfitriones fantasma, registros reconstruidos desde el almacenamiento en cada activación, identidades que sobreviven a un reinicio para que tus apps puedan reanudarse, un Worker independiente para los sockets, un clasificador de despliegues que cubría 161 archivos, recolocaciones forzadas, un watchdog para el relay, sharding por sala y, para acompañarlo, un registro de plazas compartido entre shards.

Tres de ellos los eliminamos después porque causaban más problemas de los que resolvían. Y cada solución provisional añadía piezas móviles. Repartir las salas entre objetos nos dejó una sala rebelde que respondía por el shard equivocado, un espectador atrapado en un bucle de reubicación y un límite de plazas que se podía saltar entre shards. Todo se arregló, pero estábamos dedicando nuestro tiempo a sortear la plataforma en lugar de a construir Cliqer.

Seamos justos

No todas las conexiones caídas de esos meses fueron culpa de Cloudflare. Lo comprobamos:

• El 86 % de las reconexiones individuales eran dispositivos sueltos desconectados por su propia red: proxies corporativos, wifi de recintos, cortafuegos a los que no les gustan las conexiones largas. Por eso lanzamos la compatibilidad con redes corporativas en la app de escritorio en agosto.
• Algunas oleadas fueron nuestros propios despliegues, y unas pocas las causaron nuestras propias herramientas de depuración.
• Nunca abrimos un ticket de soporte sobre los reinicios. Eso es culpa nuestra.

Durable Objects es una obra de ingeniería brillante y, para muchas cargas de trabajo, es exactamente lo adecuado. Una sala que no puede parpadear nunca, delante de un público en directo, resultó ser el peor caso posible para una plataforma que puede reiniciarla en cualquier momento. Probamos el edge para el tiempo real y, en esta ocasión, nos falló. Es un veredicto sobre esta carga de trabajo, no sobre el edge.

Qué hace funcionar tus salas ahora

El tiempo real de Cliqer funciona ahora en nuestros propios servidores dedicados. Sirven la web, la API y todos los WebSockets, y alojan cada sala directamente, respaldados por una base de datos local. El tráfico sigue pasando por la red de Cloudflare, así que mantienes la misma protección y las mismas direcciones.

Lo que ha desaparecido:

• Nada de reinicios por debajo. El proceso se ejecuta hasta que nosotros decidamos lo contrario.
• Nada de lotería de ubicación ni de tiempos de espera de almacenamiento que reseteen salas.
• Nada de sharding. Una sala, un lugar, una única fuente de verdad.

Lo que seguimos contando con honestidad:

• Cuando publicamos una actualización, tu conexión se reconecta una vez. La nueva versión arranca junto a la antigua y toma el relevo casi al instante. Tus apps se reconectan en un segundo aproximadamente con la misma identidad y siguen donde estaban. En nuestro ensayo, 4757 peticiones web pasaron por el cambio y ninguna falló.
• Nuestros servidores están en Europa. Preferimos gestionar máquinas que entendemos por completo antes que cientos de ubicaciones que no podemos ver por dentro.

Y además, más rápido

Registramos cuánto tarda cada petición a la API en nuestro lado, así que podemos comparar la semana anterior al traslado con los días posteriores, usando tráfico real en lugar de una prueba de laboratorio.

Las peticiones más lentas mejoraron todavía más. El peor 10 % de las cargas de la marca personalizada del panel bajó de 1,7 segundos a menos de medio segundo, y las peores obtenciones de credenciales del relay pasaron a ser 7 veces más rápidas.

El mayor cambio es el que notas primero. Una conexión en tiempo real que llevaba un rato inactiva en la plataforma anterior tardaba unos 1,2 segundos en abrirse mientras se despertaba. En nuestro propio servidor se abre en unos 0,14 segundos, siempre. Nuestro monitor de disponibilidad independiente, que comprueba cliqer.io cada minuto desde Norteamérica, cuenta lo mismo: unos 750 ms por comprobación antes del traslado y unos 380 ms después.

Dentro de una sala, los clics ya eran rápidos y lo siguen siendo. Lo que ha cambiado es todo lo que los rodea: abrir la app, cargar la página del presentador, obtener los datos de tu cuenta. Todo responde más rápido, y siempre de la misma manera.

Lo que Cloudflare sigue haciendo por nosotros

Mucho, y encantados:

Su observabilidad y sus analíticas también hicieron posible la mayor parte del diagnóstico de este artículo. Seguimos siendo clientes y seguimos recomendándolos.

Si algo se cae, cuéntanoslo

Nuestra promesa es sencilla: ahora, cuando se cae una conexión, hay un motivo que podemos encontrar. Si alguna vez ves que Cliqer se reconecta en pleno directo (y aquí tienes qué hacer cuando las diapositivas se congelan en ese momento), responde a cualquiera de nuestros correos o abre un chat desde la app. Los leemos todos, y ahora sí podemos decirte por qué.