Objetos duraderos sin Cloudflare: el modelo actor que ya puede vivir en tu base de datos
Lucas Carlson, veterano desarrollador con dos décadas construyendo aplicaciones en Rails y Node, presentó esta semana Solid Objects, una biblioteca open source que recrea el modelo de los Durable Objects de Cloudflare pero ejecutándose sobre bases de datos SQL convencionales como SQLite, Postgres o MySQL. El proyecto se publica bajo licencia MIT en dos implementaciones: una gema para Ruby, actualmente en producción en una aplicación con más de 100.000 usuarios, y un paquete para TypeScript que, según Carlson, puede correr incluso dentro de una pestaña del navegador.
La propuesta toma una idea que Cloudflare popularizó: tratar cada identidad —un carrito de compra, una sala de chat, una mesa de juego, un documento— como un objeto con nombre, de un solo hilo, con estado durable adjunto. Las llamadas a una misma identidad se serializan para evitar corrupciones, mientras que las llamadas a identidades distintas corren en paralelo. Cloudflare lo ofrece como plataforma gestionada en su red edge; el proyecto celld de Ryan Dahl lo reproduce como un daemon auto-hospedado. Carlson eligió un nivel más bajo: una dependencia más en el package.json, sin infraestructura adicional que operar.
El artículo describe el modelo de programación con un ejemplo: la clase TicketSale gestiona la venta de entradas con un contador, holds por comprador y alarmas programadas. Cada llamada a reserve se convierte en un mensaje durable en el mailbox del actor, un worker reclama el actor bajo un lease con token de fencing, y el handler corre fuera de cualquier transacción. Al retornar, una única transacción fenced commitea el nuevo estado junto con los efectos colaterales — mensajes salientes, recordatorios, intenciones de efectos externos. Si el lease expiró mientras el handler corría, el commit se rechaza dentro de la propia transacción.
Carlson reconoce que la entrega es at-least-once con orden estricto por identidad y que los efectos externos pueden ejecutarse dos veces, por lo que deben llevar un identificador estable y ser idempotentes. "Una vez que hay efectos externos involucrados, no existe la entrega exactly-once", escribió.
Un punto central del lanzamiento fue la verificación pública de las garantías. Alguien —un agente de inteligencia artificial que construye sistemas de liquidación— envió tres pruebas de fallo clasificadas por dónde estos modelos suelen romperse. La primera fue un test de stall: dos procesos worker, un lease de 250 milisegundos y un handler que bloquea sincrónicamente el event loop durante 2,5 segundos. El worker A reclama, se congela; a los 261 milisegundos expira el lease y B reclama, ejecuta y commitea; a los 2,5 segundos A despierta e intenta su commit, que es rechazado. "El write tardío nunca aterrizó, en ninguna corrida", aseguró Carlson, atribuyéndolo a que la verificación del fence ocurre dentro de la transacción de commit.
El proyecto incluye además un comando de verificación — npm exec --package=solid-objects@latest -- solid-objects quickstart — que dispara 25 llamadas concurrentes contra una identidad y comprueba que se serializan al estado final de 25, con la secuencia completa del 1 al 25, mientras identidades no relacionadas operan en paralelo. Cada verificación es una aserción, de modo que el comando sale con código no-cero si alguna falla.
El costo de inactividad es, según Carlson, la ventaja principal del diseño: un actor inactivo consume solo las filas en la base de datos, sin procesos ni daemons esperando detrás. Los recordatorios programados —por ejemplo, el vencimiento del hold a los 10 minutos— viven en la misma base de datos que el estado, sobreviviendo despliegues y caídas sin necesidad de cron sweepers.
El lanzamiento ilustra una tensión más amplia en el diseño de sistemas distribuidos: dónde colocar la corrección. Cloudflare la gestiona en su plataforma; celld la sitúa en la infraestructura; Solid Objects la empuja al nivel de la biblioteca y la base de datos, con la esperanza de que los desarrolladores adopten el modelo sin cambiar dónde corren sus datos.
Por ahora, el proyecto se encuentra en sus primeras semanas de vida pública, con dos implementaciones operativas y una comunidad de agentes de IA que ya contribuyen con pruebas de adversario.