Wilson: El capítulo de hoy es: Claudflare : caso practico Racinf Ecuador.

Wilson: Hoy vamos con un caso real: Racing Ecuador, el proyecto que está en D:\minimax\racing-ecuador. Martha, ¿de verdad puede funcionar completo con el plan gratuito de Cloudflare?

Martha: Sí, aunque con algunos límites importantes. Todo está en una sola cuenta, wrcp20@gmail.com, pero hay dos stacks separados: el juego 3D actual y un 2D legado que quedó congelado. Cada uno tiene su propia página en Cloudflare Pages, su Worker para la API, un namespace de KV y sus propias instancias de Durable Objects.

Wilson: Ah, o sea que no mezclaron el sistema nuevo con el antiguo. En el 3D, por ejemplo, el sitio React con three.js es racing-ecuador3d.pages.dev y la API se llama racing-ecuador3d-api. El 2D conserva racing-ec.pages.dev y racing-ecuador-api.

Martha: Exacto. Además, siguen el patrón normal de bindings: el Worker declara KV y ROOM_DO en wrangler.toml, y la API, construida con Hono, accede a ellos como c.env.KV y c.env.ROOM_DO. Es como darle a cada servicio una conexión con nombre, en vez de buscar recursos manualmente.

Wilson: ¿Y qué guardan en KV?

Martha: Aquí aparece una decisión clave: casi todo el estado principal vive dentro de una sola clave llamada db. Es un JSON con usuarios, clasificación, circuitos y secuencias. Aparte hay 36 claves track: con los GeoJSON de los circuitos; una clave cups para copas y arenas; claves ghost: con repeticiones de récord, de hasta 32 kilobytes; y claves progress:, reset: y rl:: para progreso, tokens de reseteo y límites antiabuso.

Wilson: Pero las carreras online no van ahí, ¿verdad? KV suena bien para datos almacenados, no para varios coches actualizándose a la vez.

Martha: Correcto. Cada sala online es una instancia de RoomDO, un Durable Object. Mantiene en memoria a los jugadores conectados mediante WebSocket durante la carrera. Ahí se necesita consistencia fuerte: todos deben ver el mismo estado. Sería absurdo que para un jugador el coche estuviera en la curva y para otro todavía en la recta.

Wilson: Entonces, ¿qué límite aparece primero en el plan gratuito?

Martha: Las escrituras de KV. Hay 1.000 al día compartidas por toda la cuenta. Guardar un tiempo reescribe db, una escritura, y si es récord también guarda el fantasma, otra más. Además, cada intento de inicio de sesión actualiza un contador rl::, incluso si falla. Considerando logins y reintentos, la capacidad práctica queda aproximadamente en 300 a 400 carreras guardadas por día.

Wilson: Y esa clave db gigante también parece peligrosa, aunque sobren escrituras.

Martha: Lo es. Cada resultado obliga a leer y reescribir el JSON completo. Cuando crezcan users y leaderboard, aumentará el consumo de CPU y podría alcanzarse el límite de 10 milisegundos, provocando el error 1102. Peor aún: KV admite una escritura por segundo sobre la misma clave y prevalece la última. Si dos jugadores guardan casi simultáneamente, un resultado podría perderse en silencio.

Wilson: O sea, pagar no arreglaría eso: es un problema de diseño porque KV no ofrece transacciones.

Martha: Exactamente. Habría que dividir los datos o mover las actualizaciones concurrentes a un sistema adecuado. En las salas, el otro techo son las 100.000 peticiones diarias a Durable Objects: los mensajes WebSocket cuentan. La estimación disponible es aproximada y todavía no está medida en producción, así que conviene instrumentar el tráfico antes de prometer cuántas carreras simultáneas soportará.

Wilson: Martha, pongamos las cuotas en perspectiva. Una carrera de cuatro jugadores durante tres minutos genera apenas unos cientos de mensajes. Así que se pueden disputar muchas carreras al día antes de acercarse al límite.

Martha: Ah, o sea que la mensajería no es la preocupación inmediata. ¿Y los demás límites de Cloudflare?

Wilson: También quedan holgados. El Worker admite cien mil peticiones diarias, muy por encima del tráfico actual. En Pages, el sitio publica unos cinco archivos por despliegue, lejísimos del máximo de veinte mil archivos o quinientos builds mensuales. Y en KV, los treinta y seis circuitos en GeoJSON, la base de usuarios y los fantasmas ocupan solo una fracción del gigabyte disponible.

Martha: Entonces podríamos ahorrar infraestructura compartiendo el Worker y el KV entre las versiones 2D y 3D, ¿no?

Wilson: Parece lógico, pero no. Son aplicaciones independientes. El 2D usa una versión anterior del protocolo de salas, incompatible con el cliente 3D. Además, aunque los circuitos conservan los mismos identificadores y geografía, en 3D tienen geometría remasterizada. El cliente antiguo podría interpretarlos mal.

Martha: Como guardar dos documentos distintos con el mismo nombre y esperar que un programa viejo entienda el nuevo formato.

Wilson: Exactamente. Encima, el 3D incorpora arenas de batalla que el 2D tomaría como pistas normales, y su ranking utiliza otra escala de tiempos. Por eso cada stack necesita su propio Worker, namespace KV y Durable Object.

Martha: Pero hay una trampa: separados no significa que tengan cuotas separadas.

Wilson: Correcto. Las cuotas pertenecen a la cuenta. Ambos stacks, e incluso otros proyectos de esa cuenta, comparten las cien mil peticiones diarias, las mil escrituras de KV y los cinco gigabytes de Durable Objects. Si otro proyecto empieza a escribir mucho en KV, Racing Ecuador podría fallar al guardar aunque su tráfico no cambie.

Martha: También apareció un problema curioso con la caché, ¿verdad?

Wilson: Sí. El servidor generaba un ETag fuerte para cada circuito, pero Cloudflare podía convertirlo en débil, agregando el prefijo W/ al comprimir con gzip. El cliente reenviaba ese valor y, como la comparación era exacta, nunca coincidía. Resultado: jamás se respondía con 304 Not Modified y se descargaba otra vez el circuito completo. Se corrigió normalizando ambos ETag y comparándolos sin ese prefijo.

Martha: ¿Y cuál es la mejora pendiente más importante?

Wilson: Migrar usuarios y ranking a D1. Hoy todo vive en una única clave db de KV: cada guardado reescribe el JSON completo, consume una de las mil escrituras compartidas y puede perder cambios simultáneos. Con D1 habría hasta cien mil filas escritas al día, y cada jugador se actualizaría mediante INSERT o UPDATE sin chocar con los demás.

Martha: Habría que traducir las consultas de KV a SQL y ejecutar una migración única, pero circuitos y fantasmas podrían seguir en KV.

Wilson: Claro: se leen mucho, cambian poco y encajan perfectamente allí. La idea no es abandonar KV, sino usar cada herramienta para el trabajo adecuado.

Wilson: Creado por wrcp20@gmail.com. Sígueme para más contenido.