Trabajar con almacenamiento de tipo clave-valor (Key/Value) dentro de Cloudflare Workers abre posibilidades que van más allá de una base de datos tradicional. Desde guardar configuraciones de aplicación hasta implementar pruebas A/B con cookies, este tipo de storage permite respuestas ultrarrápidas en el edge sin depender de un servidor centralizado.
¿Qué es una base de datos clave-valor y cuándo conviene usarla?
Una base de datos clave-valor (Key/Value o KV) almacena datos como pares simples: una clave única y un valor asociado. A diferencia de una base de datos SQL como D1, no hay tablas ni relaciones; todo se reduce a guardar y recuperar información por su identificador.
Cloudflare recomienda usar KV en escenarios concretos [1:52]:
- Guardar archivos estáticos.
- Almacenar configuración de aplicaciones y feature flags.
- Persistir preferencias por usuario.
- Implementar listas de acceso o denegación.
- Funcionar como caché para datos frecuentemente consultados.
¿Cuáles son los límites de KV en Cloudflare?
Como toda plataforma a gran escala, Cloudflare impone restricciones [1:10]. En la capa gratuita se dispone de 100 000 peticiones de lectura. En la capa paga las lecturas son ilimitadas, pagando según consumo. Las escrituras también tienen límites, y el número de namespaces disponibles es bastante estricto, especialmente en el plan gratuito. Un límite que aplica a ambas capas: el tamaño de cada key no puede exceder los 512 bytes.
¿Qué diferencia hay entre caché fría y caché caliente?
Este concepto es fundamental para entender el rendimiento de KV [1:28]. Cuando se solicita un dato por primera vez, se produce una caché fría: la petición viaja hasta el data center de origen donde reposan los datos, con una latencia de entre 30 y 80 milisegundos dependiendo del tamaño de la información almacenada.
Una vez leído ese dato, entra en juego la caché caliente. Las siguientes lecturas se resuelven en apenas uno o dos milisegundos, porque el valor ya está replicado en el nodo edge más cercano al usuario.
¿Cómo afecta la consistencia eventual en KV?
A diferencia de D1, donde la consistencia eventual es menos perceptible, en KV el impacto es mayor [1:44]. Por defecto, una lectura tiene un TTL mínimo de 60 segundos. Esto significa que si se modifica un valor, los demás nodos edge pueden tardar hasta 60 segundos en reflejar ese cambio o detectar que expiró.
En la práctica, durante la demostración en vivo se editó un valor en el panel de Cloudflare y el cambio se reflejó casi de inmediato [5:42], lo que indica que si el TTL del caché ya venció, la invalidación ocurre antes del máximo teórico.
¿Cómo se configura el cache TTL en código?
Al hacer un get con el binding de KV, se puede especificar un cacheTTL [4:15]. Con un valor de 60 segundos, tras la primera lectura (caché fría), las siguientes responden desde caché caliente. Aumentar ese valor mejora la velocidad de respuesta sostenida, pero retrasa la propagación de cambios. Se puede jugar con prefijos en las keys y estrategias de invalidación para forzar actualizaciones inmediatas cuando sea necesario.
¿Cómo implementar un test A/B con KV y cookies?
El caso práctico demuestra una prueba A/B completa ejecutada en server render dentro del worker de frontend [3:20].
El flujo funciona así:
- Se almacenan dos variantes (A y B) como valores en KV, cada una con un copy diferente para la landing.
- Al visitar la página, se asigna una cookie con la variante correspondiente mediante un sistema de round robin.
- Si la cookie ya existe, el usuario siempre ve la misma variante.
- Al registrarse, la variante se persiste también por email, garantizando consistencia entre dispositivos.
En la demostración, la variante A mostraba "Domina Cloudflare Workers desde cero" y la variante B un copy diferente [5:05]. Al eliminar la cookie y refrescar, el sistema reasigna aleatoriamente una variante.
El binding de KV se configura en el archivo wrangler con el ID del namespace correspondiente, igual que con otros bindings de Workers [3:45]. Un detalle importante: si se precrea un namespace manualmente y luego la herramienta genera otro, hay que verificar cuál ID se está usando realmente en el proyecto.
Este tipo de storage clave-valor complementa las bases de datos SQL y ofrece un abanico de posibilidades para feature flags, personalización y optimización de rendimiento. ¿Ya tienes un caso de uso en mente para implementar KV en tus proyectos? Compártelo en los comentarios.
