Wilson: El capítulo de hoy es: CloudFlare : buenas practicas.

Wilson: Martha, hoy toca una pregunta muy práctica: ¿cómo vivir cómodamente dentro del plan gratuito de Cloudflare sin chocar con las cuotas?

Martha: La clave empieza en el diseño, Wilson. No hay que usar el mismo almacenamiento para todo. Si son datos que cambian poco y se leen mucho, como configuración, assets o sesiones cortas, KV encaja bien porque está optimizado para lecturas globales.

Wilson: Pero si tengo usuarios, pedidos o un ranking que crece continuamente, ¿también lo pongo en una clave KV?

Martha: No. Esa es la regla de oro: nunca guardes todo el estado de la aplicación en una sola clave. Para datos relacionales, actualizaciones frecuentes y conteos exactos, usa D1. El plan gratuito permite muchas más filas escritas al día que KV, y actualizar una fila no provoca choques con otras.

Wilson: Ah, o sea que KV sería como una cartelera que consultan todos, y D1 como el libro de cuentas.

Martha: Exacto. Y si necesitas un dueño con estado en vivo —una sala de chat, una partida, un documento colaborativo, un contador atómico o WebSockets— usa Durable Objects. Cada instancia tiene un único hilo de ejecución, así que ofrece consistencia fuerte.

Wilson: ¿Y fotos, videos o backups grandes?

Martha: R2. Especialmente para archivos de más de 25 MiB: no tiene un límite práctico de tamaño y el tráfico de salida, el egress, es gratuito.

Wilson: Otro límite famoso son los 10 milisegundos de CPU del Worker gratuito. Suena poquísimo.

Martha: Lo es, pero cuenta CPU, no el tiempo esperando red. Evita parsear o serializar JSON enorme, bucles largos y cálculos pesados en cada petición. Manda ese trabajo a Cron Triggers o Queues para procesarlo después. En Paid puedes configurar hasta cinco minutos con limits.cpu_ms, pero en Free los 10 milisegundos son fijos.

Wilson: Y para respuestas grandes, mejor streaming con TransformStream que construir todo en memoria, ¿verdad?

Martha: Sí, así también evitas acercarte al límite de 128 MB. Con KV, además, conviene agrupar cambios en una sola escritura y usar expirationTtl para tokens o rate limits. Cloudflare los elimina automáticamente, sin gastar otra escritura.

Wilson: Importante si varios proyectos comparten cuenta: las mil escrituras diarias de KV son combinadas.

Martha: Correcto. En D1, crea índices para columnas usadas frecuentemente en WHERE u ORDER BY. El índice añade una escritura extra cuando cambia esa columna, pero reduce muchísimo las filas leídas y normalmente compensa.

Wilson: ¿Dónde podemos ahorrar todavía más?

Martha: Sirviendo HTML, CSS, JavaScript e imágenes pequeñas como archivos estáticos de Pages: esas peticiones son gratuitas e ilimitadas. No generes con un Worker algo que puede entregarse tal cual.

Wilson: Y R2 y D1 tienen egress gratis, así que R2 resulta excelente para archivos grandes o streaming incluso cuando otras operaciones empiecen a facturarse.

Martha: Finalmente, activa DDoS, SSL, DNS y Bot Fight Mode. Cuestan cero y no consumen la cuota de Workers porque pertenecen al plan de la zona. En resumen: elige bien dónde vive cada dato, difiere el trabajo pesado y aprovecha lo que realmente es gratis.

Wilson: Martha, hoy toca hablar de esos fallos que no hacen ruido hasta que ya tienes usuarios enfadados. Empecemos por KV: es rápido y útil, pero tiene consistencia eventual y permite aproximadamente una escritura por segundo sobre la misma clave.

Martha: Ah, o sea que no debería usarlo para algo como «el primero en registrarse gana», porque ahí sí importan el orden y la atomicidad.

Wilson: Exactamente. Si dos peticiones escriben casi al mismo tiempo, puede terminar ganando la última y perderse un cambio. Para datos que compiten por una misma clave, conviene usar D1, que ofrece transacciones a nivel de fila.

Martha: ¿Y si quiero seguir usando KV?

Wilson: Puedes reducir la competencia separando los datos. En vez de guardar a todos dentro de una clave llamada «users», creas una clave por persona, como «user:123». Es como dejar de apuntar todos los pedidos en una sola hoja y darle una ficha a cada cliente.

Martha: Bien. Pero ¿cómo descubro estos problemas antes de que producción se incendie?

Wilson: Revisa semanalmente el panel de Metrics de cada Worker, sobre todo si el tráfico está creciendo. Activa alertas cuando tu plan y el soporte de Cloudflare lo permitan. Y, muy importante, registra en tu propia aplicación cada fallo de escritura en KV o D1. Un error aislado parece casualidad; veinte errores a la misma hora ya muestran un patrón.

Martha: Hablemos de seguridad. ¿Tener el dominio en modo proxied ya me protege?

Wilson: Ayuda, pero no basta. Si una API pública recibe bots simples, activa Bot Fight Mode. Para registro o inicio de sesión, usa Turnstile en lugar de reCAPTCHA: es gratuito, más respetuoso con la privacidad y admite hasta veinte widgets.

Martha: Y en el plan Free solo tengo una regla de rate limiting, ¿verdad?

Wilson: Sí, así que colócala en la ruta más sensible, normalmente el login. Aunque tu backend ya limite intentos usando KV, la regla de Cloudflare bloquea antes de llegar al Worker y te ahorra cuota. Los secretos, además, se cargan con «wrangler secret put». Nunca los dejes en texto plano dentro de wrangler.toml ni los subas al repositorio.

Martha: ¿Cuándo deja de tener sentido insistir con el plan gratuito?

Wilson: Una regla práctica es migrar a Workers Paid, que parte de cinco dólares mensuales, si cumples dos o más señales: agotaste escrituras KV o filas D1 varias veces en un mes; aparece el error 1102 de CPU durante tráfico normal; necesitas Vectorize, Containers, Pipelines o enviar correos; ya tienes ingresos o usuarios que dependen del servicio; o necesitas builds concurrentes o más de quinientos builds mensuales en Pages.

Martha: Antes de cerrar, repasemos síntomas engañosos. Si un ETag nunca coincide, puede ser porque Cloudflare comprimió la respuesta y lo convirtió en débil, con el prefijo «W/».

Wilson: Si un Worker parece desaparecer de las rutas, quizá confundiste el plan de la zona con el plan de Workers: son independientes. Si un dominio nuevo de Pages devuelve «no existe», puede ser caché DNS negativa, o NXDOMAIN; normalmente se resuelve sola, pero puedes probar temporalmente con el DNS 1.1.1.1.

Martha: Y si desaparecen datos escritos casi simultáneamente, volvemos a KV: no es transaccional y la última escritura puede imponerse.

Wilson: Exacto. Y cuando algo «simplemente falla» sin factura ni aviso, recuerda que en Free superar una cuota suele hacer fallar la operación, no generar un cobro. La idea general es sencilla: diseñar para la concurrencia, observar métricas, registrar errores y proteger las rutas críticas antes de necesitarlo.

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