wandres.dev
KV · clave-valor global

Workers KV: el almacén clave-valor global

Workers KV es un almacén clave-valor persistente y replicado por toda la red de Cloudflare, afinado hasta el extremo para una sola cosa: lecturas muy frecuentes desde cualquier punto del planeta con latencia mínima. No es una base de datos de propósito general, sino un diccionario global cuyo diseño intercambia a conciencia consistencia inmediata y escritura veloz por lecturas baratísimas y omnipresentes. Vemos qué es, la asimetría lectura/escritura que lo define, y el modelo mental de un origen central con copias cacheadas cerca de cada usuario.

⏱ 14 min

Imagina un diccionario corriente —claves y valores— pero con una propiedad asombrosa: existe a la vez en cientos de ciudades del mundo, y cualquier Worker, corra donde corra, puede leerlo en un puñado de milisegundos. Eso es Workers KV. No es una base de datos relacional ni un caché que se evapora: es un almacén clave-valor persistente y global, diseñado desde su primer byte para un único caso —leer mucho, desde todas partes, muy rápido— y para cobrar ese don con una moneda que conviene entender antes de gastar: la escritura es lenta en propagarse y una lectura lejana puede darte, por un instante, la versión anterior.

🎯 Al terminar esta lección sabrás
  • Definir Workers KV como un almacén clave-valor persistente y replicado globalmente.
  • Entender la asimetría que lo gobierna: lecturas baratísimas frente a escrituras caras y lentas en propagar.
  • Formar el modelo mental de un origen central con copias cacheadas en el edge.
  • Situar KV frente al resto del almacenamiento y reconocer para qué caso nació.

Un diccionario del tamaño del planeta

KV, de key-value —clave y valor—, es la estructura de datos más simple que existe: asocias una clave, que es una cadena de texto, con un valor, y más tarde recuperas ese valor nombrando su clave. Tres verbos bastan para describir su superficie: put para guardar, get para leer y delete para borrar.

export default {
  async fetch(request: Request, env: Env): Promise<Response> {
    await env.MI_KV.put("saludo", "hola mundo"); // guardar
    const valor = await env.MI_KV.get("saludo");  // leer
    return new Response(valor ?? "vacio");
  },
};

Lo revolucionario no es la estructura —la usas desde tu primer diccionario o mapa hash—, sino dónde vive: Cloudflare la reparte por toda su red. Cuando escribes una clave, el valor viaja hasta quedar disponible en cada región del planeta; cuando la lees desde Tokio, Madrid o São Paulo, la respuesta sale de la copia más cercana, no de un servidor central a medio mundo de distancia. Un Worker se ejecuta cerca del usuario, pero un Worker sin datos es una cáscara; de nada sirve calcular en el edge si para leer tu configuración tienes que cruzar el océano. KV cierra esa brecha para un tipo concreto de dato: el que se lee muchísimo y se escribe poco. Y es persistente, no un caché volátil —lo que guardas permanece hasta que lo borras o expira—, con claves de hasta 512 bytes y valores de hasta 25 MiB.

La asimetría que lo gobierna todo

Toda la personalidad de KV nace de una decisión de diseño: optimizar la lectura por encima de todo, aun a costa de la escritura. No es un almacén equilibrado que hace las dos cosas medianamente bien, sino uno deliberadamente torcido hacia leer. Entender esa asimetría es entender KV entero.

Lecturas baratísimas

Leer una clave popular tarda milisegundos: la copia vive cacheada en el mismo centro de datos donde corre tu Worker. Cuanto más se lee una clave, más rápida se vuelve.

🐢

Escrituras caras y lentas

Escribir es la operación cara. Una misma clave admite del orden de una escritura por segundo, y el nuevo valor tarda en verse en todas partes. KV no está hecho para escribir en caliente.

🌍

Alcance global

Un solo put deja el dato al alcance de todos los centros de datos. No eliges región ni replicas a mano: la red entera es tu ámbito por defecto.

🗄️

Persistente, no efímero

A diferencia de un caché, lo escrito no se pierde bajo presión de memoria. Permanece hasta que lo borras o hasta que su TTL lo expira. Es almacenamiento, no memoria de usar y tirar.

Grabar esta asimetría evita casi todos los usos equivocados de KV. Quien lo trata como una base de datos de propósito general —escrituras frecuentes, lecturas al instante consistentes— se estrella; quien lo trata como lo que es —un diccionario global de lectura intensiva— obtiene una de las piezas más rápidas y baratas de toda la plataforma.

Origen central, copias en el edge

El modelo mental correcto es este: existe un origen central donde vive la verdad de cada clave y, alrededor, cientos de cachés en el edge que guardan copias de lo que se ha leído recientemente cerca de allí. Escribir actualiza el origen; leer sirve, siempre que puede, desde la copia local.

flowchart TB
W[put desde un Worker] --> O[origen central guarda la verdad]
O -.propaga en segundo plano.-> E1[cache edge Tokio]
O -.propaga en segundo plano.-> E2[cache edge Madrid]
O -.propaga en segundo plano.-> E3[cache edge Sao Paulo]
E1 --> R1[get rapido junto al usuario]
E2 --> R2[get rapido junto al usuario]
E3 --> R3[get rapido junto al usuario]
style O fill:#89b4fa,color:#11111b
style E1 fill:#a6e3a1,color:#11111b
style E2 fill:#a6e3a1,color:#11111b
style E3 fill:#a6e3a1,color:#11111b

De este dibujo se deducen las dos verdades que dominan el resto del nivel. Primero, la primera lectura de una clave en un lugar concreto puede ser lenta —hay que ir al origen porque aún no hay copia local—, pero las siguientes son rapidísimas porque quedan cacheadas cerca. Segundo, cuando escribes un valor nuevo, las copias viejas repartidas por el mundo no se enteran al instante: tardan en actualizarse, y durante esa ventana una lectura lejana puede devolverte el valor anterior. No es un defecto: es el precio explícito de la velocidad global.

💡
La regla de oro en una frase

Antes de guardar algo en KV, hazte una pregunta: ¿este dato se lee muchas más veces de las que se escribe, y puedo tolerar que una escritura tarde unos segundos en verse en todas partes? Si la respuesta es sí, KV es probablemente la herramienta perfecta. Si es no, casi seguro necesitas otra pieza.

KV no es una base de datos: es una estructura de datos con física

Merece la pena detenerse en una distinción que casi nadie hace explícita: KV no es una base de datos, es una estructura de datos con física. Un mapa hash en memoria no tiene física —todas sus operaciones cuestan lo mismo porque todos sus datos están a la misma distancia, un salto de puntero—. En cuanto estiras ese mapa hash sobre el planeta, la distancia deja de ser uniforme y aparece la física: la velocidad de la luz impone que un dato en el origen esté a decenas de milisegundos mientras que una copia local está a menos de uno; la economía de la replicación impone que propagar una escritura a cientos de sitios lleve tiempo y no pueda ser ni instantánea ni gratis. El teorema CAP formaliza esta tensión: ante una partición de la red, un sistema distribuido debe elegir entre seguir disponible o seguir consistente, y no puede tener las dos a la vez. KV elige, sin ambigüedad, disponibilidad y tolerancia a particiones sacrificando la consistencia inmediata. Por eso una lectura nunca se bloquea esperando a que el mundo se ponga de acuerdo: te devuelve la copia que tiene a mano, aunque sea de hace unos segundos. Esta es la inversión mental que hay que hacer. Venimos de un mundo donde “guardar un dato” y “leerlo justo después” es una verdad trivial que garantiza una única máquina; KV nos pide aceptar que, a escala planetaria, esa garantía cuesta más de lo que casi ningún dato de lectura intensiva necesita pagar. Memcached y Redis te dan un caché rapidísimo en una región; KV es lo que obtienes cuando tomas esa idea, la extiendes a toda la Tierra y la haces duradera, y el precio de esa extensión es exactamente la asimetría y el desfase que definen su carácter. El ingeniero que interioriza que KV tiene física —que su comportamiento lo dictan dónde se sientan los bytes y cuánto tarda la luz en visitarlos— deja de pelearse con él pidiéndole consistencia fuerte y empieza a usarlo para lo único que ninguna base de datos regional puede darle: el mismo dato, a un milisegundo, en todas partes.

⚔️ Reconoce la forma de un dato de KV
  1. Enumera tres datos de una app real que se lean mucho y se escriban poco: candidatos naturales a KV. Justifica la proporción lectura/escritura de cada uno.
  2. Explica con tus palabras por qué la primera lectura de una clave en una región puede ser lenta y las siguientes rapidísimas.
  3. Describe qué le pasa a una lectura lejana durante los segundos posteriores a una escritura, y por qué eso no es un fallo sino una decisión de diseño.
  4. Sitúa KV en el teorema CAP: ¿qué dos garantías elige y cuál sacrifica? Da un ejemplo de dato para el que ese sacrificio sea inaceptable.
  5. Contrasta KV con un mapa hash en memoria: ¿qué añade la palabra “global” y qué precio impone la física?