Casos ideales y límites: cuándo sí y cuándo no

Has visto qué es KV, su API, su consistencia eventual y sus mecanismos de tiempo. Toca la síntesis: saber, de un vistazo, si un dato pertenece a KV o a otra pieza. La brújula es siempre la misma proporción —lecturas frente a escrituras— y una sola pregunta sobre la escritura: ¿escribo la misma clave muchas veces, y necesito que cada cambio sea seguro frente a la escritura simultánea de otro? Si escribes poco y toleras el desfase, KV es de las mejores herramientas de la plataforma. Si escribes mucho a la misma clave o necesitas contar sin perder ni una, KV es la elección equivocada, y forzarla produce bugs silenciosos que ningún test local revela.

Para qué brilla KV

El caso ideal de KV tiene una firma inconfundible: un dato que se lee muchísimas veces, se escribe rara vez y tolera unos segundos de desfase. Cuando un dato cumple las tres, KV le da algo que casi ninguna otra pieza puede: presencia global a un milisegundo, barata y sin gestionar réplicas.

El hilo que une los cuatro es la proporción: en todos, las lecturas superan a las escrituras por órdenes de magnitud. KV convierte esa proporción en una ventaja, porque cada lectura repetida se sirve más rápido y más barata desde el caché caliente, mientras la escritura rara no llega a doler. Es, literalmente, para lo que se diseñó.

Para qué NO usarlo

El reverso es igual de nítido, y aquí es donde la mayoría se equivoca. KV es una mala elección siempre que la escritura deja de ser rara o deja de ser segura de perder. Dos antipatrones concentran casi todos los errores.

El primero son las escrituras frecuentes a una misma clave. KV admite del orden de una escritura por segundo y clave; si tu código actualiza la misma clave muchas veces por segundo, no solo va lento, sino que va contra el diseño del sistema. El segundo, más traicionero, son los contadores y cualquier ciclo de leer-modificar-escribir. Como KV no tiene operaciones atómicas ni transacciones, el patrón de leer un número, sumarle uno y volver a escribirlo es una carrera perdida de antemano: entre tu lectura y tu escritura, otro Worker pudo escribir, y su incremento se esfuma sin error.

// ANTIPATRON: un contador sobre KV pierde incrementos en silencio
const n = Number(await env.MI_KV.get("visitas")) || 0;
await env.MI_KV.put("visitas", String(n + 1)); // otra escritura simultanea se pierde

// La forma correcta de contar vive en un Durable Object, que serializa el acceso
// y ofrece atomicidad e identidad unica por objeto.

Los límites y a quién delegar

Conviene tener los números en la cabeza para no descubrirlos por sorpresa: una clave admite hasta 512 bytes, un valor hasta 25 MiB, la metadata hasta unos 1024 bytes, y una clave concreta tolera del orden de una escritura por segundo. Cuando un dato choca con alguno de esos muros —o con la consistencia eventual—, la señal no es “fuerza KV”, sino “esta pieza es otra”.

flowchart TB
D{que necesita el dato} --> A[lectura global, escritura rara, tolera desfase]
D --> B[contar, coordinar, leer-modificar-escribir atomico]
D --> C[consultas relacionales, filtros, orden, joins]
D --> E[ficheros grandes o binarios de muchos MB]
A --> KV[Workers KV]
B --> DO[Durable Objects]
C --> D1[D1 SQLite]
E --> R2[R2]
style KV fill:#a6e3a1,color:#11111b
style DO fill:#cba6f7,color:#11111b
style D1 fill:#89b4fa,color:#11111b
style R2 fill:#fab387,color:#11111b

El mapa de delegación es limpio. Lo que exige atomicidad, contadores o coordinación con estado va a un Durable Object, que serializa el acceso y da identidad única. Lo que exige consultas ricas —filtrar, ordenar, unir tablas, contar con exactitud— va a D1, la base SQLite de la plataforma. Los ficheros grandes van a R2, el almacén de objetos sin cargos de egress. KV se queda con su franja: la lectura global, frecuente y tolerante al desfase. Reconocer a cuál pertenece cada dato, en vez de meter todo en el primero que aprendiste, es exactamente lo que separa a quien usa la plataforma de quien la diseña.