Cloudflare KV se vende como una tienda distribuida globalmente y esa descripción es técnicamente correcta. Lo que omite es que "distribuido globalmente" se aplica completamente a las lecturas y sólo parcialmente a las escrituras, con un retraso de hasta 60 segundos que cambia todo sobre cómo se debe utilizar.
Cuando escribe una clave en KV, la escritura va a un almacén central. Desde allí, se propaga a todos los puntos de presencia de Cloudflare: más de 300 PoP distribuidos globalmente. Esta propagación no es instantánea. La documentación oficial indica hasta 60 segundos para que todos los PoP reciban el nuevo valor. Durante esta ventana, un trabajador que se ejecuta en Frankfurt puede devolver el valor anterior mientras que un trabajador en São Paulo ya ve el nuevo. Dos trabajadores de la misma región pueden divergir si uno de ellos aún no ha recibido la actualización.
Ésta es la coherencia eventual. Cloudflare documenta este comportamiento claramente, pero la frase "distribuido globalmente" es lo suficientemente seductora como para que muchos equipos no lean esa parte hasta que depuren un error en producción.
¿Qué pasa en una lectura?
La lectura en KV tiene dos caminos y la diferencia entre ellos es importante para la latencia. Cuando un trabajador hace env.MY_KV.get('chave'), el tiempo de ejecución verifica si esa clave está almacenada en caché en el PoP que atiende la solicitud. Si es así (y la mayoría de las teclas de acceso rápido lo serán), la lectura regresa en menos de un milisegundo, directamente desde la memoria PoP. Este es el camino feliz y es lo que hace que KV sea excepcionalmente rápido para las lecturas.
Si la clave no está almacenada en caché en ese PoP (porque es una clave nueva, porque se escribió recientemente y aún no se ha propagado, o porque el PoP simplemente no ha recibido esa entrada), el tiempo de ejecución busca en el almacén central. Esto agrega unos 20 ms. No es dramático, pero es mensurable, y verás que este número aparece en el rastro cuando la llave está fría.
El detalle que genera sorpresa: no hay garantía de lectura-escritura. Escribe una clave e inmediatamente intenta leerla en la misma invocación de Trabajador. La lectura puede devolver el valor anterior. Este comportamiento está documentado y es intencional: es una consecuencia directa de la arquitectura de almacenamiento en caché de PoP. Si necesita lectura y escritura, KV no es la herramienta adecuada para ese flujo.
¿Para qué carga de trabajo se construyó el KV?
La arquitectura KV tiene mucho sentido cuando se conoce el problema que resuelve: datos escritos a baja frecuencia y leídos a muy alta frecuencia. El modelo económico refuerza este patrón. Las lecturas cuestan 0,50 dólares por millón después de los primeros 10 millones gratuitos al mes. Las inscripciones cuestan 0,50 dólares por millón después del primer millón gratuito. En el nivel gratuito, tienes 100 mil lecturas por día y solo mil escrituras por día.
El coste y los límites apuntan a la misma carga de trabajo: escribir poco, leer mucho. Los indicadores de funciones son el ejemplo canónico. Un archivo JSON con indicadores de productos cambia un par de veces al día como máximo. Pero es leído por cada solicitud de cada Trabajador en cada PoP del mundo. Una propagación de 60 segundos es aceptable para una bandera; no es necesario que todos los usuarios del planeta vean la característica en el mismo milisegundo. La cantidad de lecturas, potencialmente miles de millones por mes, se almacenan en caché a un costo mínimo.
El mismo razonamiento se aplica a las plantillas HTML renderizadas, la configuración de aplicaciones, los datos del catálogo con una frecuencia de actualización baja y los tokens de sesión con un TTL definido. Escribe una vez, lee decenas de miles de veces y KV lo entrega con latencia de caché.
¿Dónde te traicionará KV?
Cualquier carga de trabajo que requiera coherencia inmediata producirá errores cuando se implemente a través de KV. El caso más común es una sesión de usuario con estado mutable. El usuario cierra sesión; escribes el indicador de sesión no válida en KV; en los siguientes 60 segundos, un PoP diferente aún puede autenticar solicitudes con el token anterior porque no recibió la actualización.
Los contadores precisos son otro punto de fracaso. KV no tiene operaciones atómicas: no hay comparación e intercambio, no hay incremento atómico. Dos trabajadores que lean el mismo contador simultáneamente leerán el mismo valor, se incrementarán de forma independiente y se perderá uno de los incrementos. Para contadores que limitan la velocidad y que deben ser precisos, KV es la herramienta equivocada. Existen objetos duraderos para este caso.
Los datos que cambian según la solicitud tampoco encajan. Si cada respuesta al usuario cambia un valor en el KV, está pagando 0,50 dólares por millón de escrituras en un volumen que puede ser gigantesco, con una latencia de ~150 ms por escritura para la confirmación en el almacén central, más el retraso de propagación. El costo aumenta de una manera que no tiene sentido económico y la latencia de escritura aparecerá en la cola p99 de sus solicitudes.
Para lograr una coherencia inmediata por clave con baja latencia de escritura, D1 con la API de sesiones es la ruta actual de Cloudflare. Para estados compartidos que requieren operaciones atómicas, Objetos duraderos.
El modelo de costes sin ilusiones
El nivel gratuito es generoso para la experimentación pero limitado para la producción de cualquier volumen. 100.000 lecturas por día equivalen a poco más de 1 solicitud constante por segundo; una aplicación real con un tráfico razonable supera eso en minutos.
En la capa de pago lo que cambia es que las lecturas son prácticamente gratuitas a escala. 0,50 dólares por millón de lecturas es lo suficientemente barato como para no aparecer como una línea relevante en la factura si su carga de trabajo tiene muchas lecturas. Escribe a $0,50 por millón, con 1 millón gratis por mes, cubre la mayoría de los estándares y banderas de configuración sin costo significativo.
Lo que puede sorprenderte es el almacenamiento: 0,50 dólares por GB al mes además del primer GB gratuito. Para valores pequeños (configuración JSON, tokens, banderas) difícilmente tocará este límite. Para aquellos que estén considerando almacenar binarios de tamaño considerable en KV (el límite por valor es 25 MB), el costo de almacenamiento comienza a aparecer. Para archivos grandes, R2 a $0,015/GB tiene más sentido.
Qué KV resuelve bien y qué no
KV es una herramienta de lectura de alto rendimiento con escritura ocasional. Cuando opta por este modelo, ofrece una latencia inferior a milisegundos para lecturas activas, distribución global automática sin configurar la replicación y un modelo de precios que favorece lecturas de volumen masivo.
El error no es usar KV, sino usarlo como si fuera una base de datos de propósito general. Ninguna herramienta reemplaza el diagnóstico correcto de la carga de trabajo. Si sus datos cambian con frecuencia por usuario, requieren atomicidad o consistencia inmediata, KV no funcionará, y lo encontrará en producción, no en desarrollo.
Lea también
- KV en producción: los patrones que funcionan y los que engañan al principio
- Invalidación de caché en KV: el problema que nadie soluciona elegantemente
- KV para limitación de velocidad, indicadores de funciones y configuración distribuida: dónde funciona y dónde falla
- Cloudflare D1: La base de datos SQLite en el borde, y por qué "borde" no significa lo que parece
- Cloudflare Workers vs Pages: la diferencia que importa antes de elegir
- KV vs R2 vs Cache API: cuándo usar cada nivel de almacenamiento de Cloudflare