Chat aleatorio sin servidor con Cloudflare Durable Objects
Un desarrollador —Arjun, del blog dev.to— armó una app de chat aleatorio Cloudflare Durable Objects que empareja dos desconocidos para chatear, jugar o ver videos sincronizados, y la tiró a producción en marzo de 2026 sin un solo servidor siempre encendido y sin Redis. La app está viva (sin registro, abrís y arrancás).
Los Cloudflare Durable Objects son actores stateful en el edge: una instancia única, direccionable globalmente, con almacenamiento propio (SQLite embebido) y ejecución single-threaded. En criollo: cada objeto es la autoridad absoluta sobre los datos que maneja, sin bases de datos externas ni colas de mensajes en el camino caliente. Esto, que para una app web cualquiera puede ser un dolor de cabeza, para un chat en tiempo real es un golazo porque eliminás Redis, Pub/Sub y toda la flota de WebSocket servers que normalmente tenés que mantener despiertos.
En 30 segundos
- Qué es: una app de chat aleatorio que corre íntegra en el edge de Cloudflare con tres tipos de Durable Objects — User DO, Conversation DO y Queue DO — sin servidores tradicionales ni Redis.
- Cuándo y quién: publicada por el desarrollador Arjun en marzo de 2026.
- Costo ínfimo: la hibernación WebSocket permite que los Durable Objects se congelen en memoria sin perder conexiones; solo pagás por cómputo cuando hay mensajes en tránsito.
- Escalabilidad: no hay competencia entre salas porque cada Conversation DO es independiente; Cloudflare puede ejecutar millones en paralelo.
Cloudflare es una red de entrega de contenido y servicios de seguridad web desarrollada por Cloudflare, Inc., que ofrece protección contra ataques DDoS, optimización de rendimiento y cómputo en el borde mediante Workers y Durable Objects.
¿Cómo funciona la arquitectura sin servidor ni Redis?
El diseño descansa sobre tres clases de Durable Objects, cada una con un rol bien definido. No hay grises, no hay overlap — y eso es lo que hace que el sistema sea predecible.
- User DO: uno por usuario conectado. Sostiene el WebSocket, trackea presencia y corre un timer de gracia corto para que un refresh o un pestañazo no te marque offline al instante.
- Conversation DO: uno por chat. Es la sala autoritativa: guarda los mensajes en el SQLite que trae embebido el DO, retransmite entre los dos participantes y oficia de árbitro si comparten actividades como juegos o videos sincronizados.
- Queue DO: uno solo en toda la app. Los clientes piden ser emparejados acá; el Queue DO los matchea respetando preferencias (como género), levanta un Conversation DO nuevo y le pasa el ID de sala a ambos extremos.
El dato clave: no hay base de datos externa en la ruta caliente. La presencia, el emparejamiento y el historial de mensajes viven en los mismos objetos que manejan las conexiones. Borraste de un plumazo Redis, borraste el servidor siempre prendido, y lo reemplazaste con actores que solo facturan cuando laburan.
¿Qué rol cumple la hibernación WebSocket en la reducción de costos?
Acá está la magia que hace viable el modelo económico. La API de hibernación de Cloudflare permite que un Durable Object se descargue de memoria sin cortar las conexiones WebSocket activas. Queda congelado, literalmente: no consume cómputo, no factura duración.
Cuando llega un mensaje el runtime reactiva el objeto, procesa los eventos pendientes y lo vuelve a hibernar en cuanto hay silencio. Traducción a pesos: si tu chat de extraños está abierto en segundo plano mientras te tomás un café, no estás pagando un centavo por esa inactividad. Antes, un WebSocket mantenía el DO en memoria todo el tiempo y el reloj de billing corría sin pausa.
¿El resultado? La app puede manejar un volumen considerable de conexiones simultáneas con un costo operativo muy bajo. Si alguna vez tuviste que mantener un fleet de VPS con Node.js solo para sockets, sabés de qué hablo. En como administrar variables y secretos en Cloudflare profundizamos sobre esto.
¿Cómo se implementa el emparejamiento de usuarios sin Redis?
El matchmaking es el punto donde muchos proyectos serverless se caen a pedazos porque necesitás estado compartido, colas y locks. El Queue DO lo resuelve con la propiedad más subestimada de los Durable Objects: ejecuta requests de a uno por vez.
Un cliente pide match, el Queue DO lo encola con sus preferencias. Cuando dos clientes compatibles están en cola, el mismo objeto —single-threaded, sin race conditions— los desencola, crea un Conversation DO y les devuelve el ID. No hay dos workers compitiendo por el mismo par de usuarios, no hay locks distribuidos, no hay mensajes duplicados. Es una cola en memoria dentro de un actor con consistencia fuerte. (Sí, en serio, todo el matchmaking de una app de chat aleatorio se resuelve con un solo actor global).
Si un cliente se desconecta antes de ser emparejado, el User DO asociado se entera y el Queue DO lo limpia de la cola. Simple.
¿Qué garantías de consistencia y orden ofrecen los Durable Objects?
Imaginá esto: dos personas chateando en la misma sala, una manda “hola”, la otra manda “che, cómo va el proyecto” medio segundo después, y los mensajes te llegan desordenados. En un sistema con Pub/Sub tradicional, meter orden global requiere IDs de secuencia, relojes lógicos o un broker que serialice —y suma complejidad al mango.
Con los Durable Objects el orden es gratis. Cada Conversation DO es single-threaded y procesa todo de a una operación. Cuando un participante manda un mensaje, el DO lo persiste en SQLite, lo retransmite al otro, y recién después toma el siguiente request. No necesitás Lamport timestamps, no necesitás Kafka. La consistencia es fuerte por diseño: cualquier cambio de estado es inmediatamente visible para todas las conexiones a ese objeto. Más contexto en al comparar Cloudflare R2 con AWS S3.
Ojo: esto aplica dentro de cada sala. Entre salas distintas, obvio, no hay garantías porque no las necesitás — cada Conversation DO es un universo independiente.
¿Cuáles son los límites de escalabilidad de este enfoque?
La pregunta que cualquiera haría: si el Queue DO es uno solo, ¿no se convierte en cuello de botella cuando entran 10.000 personas a buscar pareja al mismo tiempo? La respuesta corta es que Cloudflare ejecuta cada DO en una réplica aislada y está diseñado para manejar tasas de requests altísimas —pero sí, el límite teórico está en el throughput de un solo hilo por DO.
Ahora bien, fijate que no estamos hablando de transmitir video 4K por ese actor: apenas se recibe una solicitud de match, se lee una cola cortita y se matchea o se encola. El trabajo en frío son nanosegundos. En la práctica, el sistema puede manejar bien el tráfico típico de un chat aleatorio, y si algún día hiciera falta un sharding por región, el modelo lo permite.
Para las salas individuales el límite es aún más relajado: un Conversation DO solo maneja dos usuarios —(¿vas a escribir más rápido que un actor single-threaded en V8? No, no vas a poder)—, por lo que la contención brilla por su ausencia.
¿Qué pasos seguir para desplegar tu propio chat aleatorio en Cloudflare?
Si te pica la curiosidad, podés tener una versión andando en minutos. Va la ruta crítica: Relacionado: en nuestra comparativa de CI/CD 2026.
- Configurá wrangler.toml con las bindings de los tres Durable Objects (UserDO, ConversationDO, QueueDO).
- Implementá la clase UserDO con manejo de WebSocket, presencia y un timer de gracia para reconexiones rápidas.
- Implementá ConversationDO con SQLite embebido para historial y broadcasting a los participantes.
- Implementá QueueDO con la lógica de matchmaking — la parte más divertida porque te obliga a pensar en single-threaded y te das cuenta de que no necesitás locks.
- Usá WebSocketPair para establecer la conexión desde el Worker al DO sin manejar sockets crudos en el cliente.
- Probá en local con
wrangler devy cuando ande,wrangler deployy a producción.
Si necesitás un dominio propio para la app o querés hostear algún complemento fuera de Cloudflare —un landing, una API auxiliar, lo que sea—, donweb.com tiene planes con datacenter en Buenos Aires y soporte que habla tu idioma. Pero el core del chat, te repito, vive 100% en el edge de Cloudflare.
Comparativa: arquitectura tradicional vs. Durable Objects
| Criterio | Tradicional (Node.js + Redis) | Durable Objects (Cloudflare) |
|---|---|---|
| Servidor siempre encendido | Sí, VPS o contenedores 24/7 | No, workers se activan bajo demanda |
| Base de datos en ruta caliente | Redis para presencia y colas | No, SQLite embebido dentro de cada DO |
| Consistencia | Depende de Pub/Sub, necesita orden externo | Fuerte por single-threaded en cada DO |
| Costos en inactividad | Pagás cómputo aunque no haya mensajes | Hibernación WebSocket elimina costo ocioso |
| Escalado | Horizontal con sticky sessions y Redis Cluster | Horizontal por DO independiente, sin coordinación |
| Complejidad operativa | Alta (monitoreo de sockets, failover, réplicas) | Baja, lo administra Cloudflare |
Qué está confirmado y qué no
- Confirmado: la app está funcional y abierta al público.
- Confirmado: la arquitectura usa exclusivamente tres tipos de Durable Objects y no tiene Redis ni bases de datos externas, según el artículo de Arjun en dev.to.
- Confirmado: la hibernación WebSocket reduce drásticamente los costos en comparación con mantener WebSockets activos constantemente.
- No confirmado por terceros: el rendimiento bajo cargas extremas (miles de matches por segundo en el Queue DO) no tiene benchmark independiente; todo lo reportado viene del autor.
- Pendiente: no está documentado cómo maneja la latencia en regiones sin POP de Cloudflare cercano; habría que probarlo desde Argentina en horario pico.
Errores comunes al implementar chat en tiempo real con Durable Objects
Asumir que un DO es un servidor y dejar conexiones abiertas sin hibernación. Si no implementás la API de hibernación, el DO se queda en memoria cobrándote por cada milisegundo. La hibernación se configura explícitamente; no es por defecto.
Creer que podés hacer broadcast entre DOs sin un protocolo explícito. Los Durable Objects no se hablan entre sí mágicamente: si necesitás cross-room communication, tenés que implementarlo vos con fetch entre DOs o con un DO coordinador.
Ignorar el timer de gracia en el User DO. Si marcás offline a un usuario en el instante que se cae el WebSocket, un simple refresh en el navegador lo saca de la cola y le destruye la sala. El timer de gracia —unos segundos— evita esa falsa desconexión y mejora la experiencia.
Preguntas Frecuentes
¿Se puede hacer un chat en tiempo real sin servidor dedicado?
Sí, y la prueba es la app publicada por Arjun en marzo de 2026. Los Durable Objects de Cloudflare reemplazan el servidor tradicional con actores stateful en el edge que manejan WebSockets, estado y almacenamiento sin requerir un VPS ni Redis.
¿Qué son los Durable Objects de Cloudflare y para qué sirven?
Son instancias únicas de código con almacenamiento propio (SQLite) que se ejecutan en el edge de Cloudflare, procesando requests de a uno por vez. Sirven para cualquier caso donde necesités una autoridad central sin base de datos externa: chats, colas de matchmaking, rate limiting, carritos de compra, sesiones de juego. Esto se conecta con lo que analizamos en al elegir entre Jenkins y GitHub Actions.
¿Cómo funciona el matchmaking de usuarios sin Redis?
Con un Queue DO único que recibe solicitudes de emparejamiento, las encola en memoria respetando preferencias, y matchea pares sin riesgo de condiciones de carrera porque corre en un solo hilo. Sin locks, sin mensajes duplicados, sin infraestructura extra.
¿Qué es la hibernación WebSocket y cómo reduce costos?
Es una API de Cloudflare que permite descargar un Durable Object de memoria mientras mantiene abiertas las conexiones WebSocket. Reactiva el objeto solo cuando llegan mensajes. Esto elimina los cargos por duración durante períodos de inactividad.
¿Cuánto cuesta desplegar un chat con Cloudflare Workers?
El costo depende del tráfico, pero con hibernación WebSocket, los cargos por duración pueden ser muy bajos. Pagás por requests y por almacenamiento en SQLite. Para un chat con un número moderado de usuarios diarios, podés estar dentro del tier gratuito de Workers.
Conclusión
La demo de Arjun es más que un proyecto de fin de semana: es un blueprint de cómo los Durable Objects pueden reemplazar el tándem servidor + Redis para casos de uso stateful en el edge. La hibernación WebSocket achica la factura, la consistencia single-threaded te limpia el código, y el escalado horizontal con actores independientes te da margen para crecer sin reescribir todo.
Lo que no tenés que perder de vista es que esto no es magia. El Queue DO único pone un techo de throughput —alto, pero techo al fin—, y la latencia para usuarios lejos de los POPs de Cloudflare puede ser un factor si tu app es sensible. Dicho eso, para un chat aleatorio de extraños, es una solución elegante como pocas. Si te picó la curiosidad, el precio de entrada es bajísimo y en un par de horas podés estar haciendo pair programming con un desconocido en Oslo.
