Las tres primitivas de almacenamiento de Cloudflare (KV, R2 y Cache API) aparecen juntas en la documentación y comparten el mismo tiempo de ejecución, lo que crea la impresión de que son alternativas al mismo problema. No lo son. Cada uno fue construido con una arquitectura diferente, para una carga de trabajo diferente, con un modelo de costos diferente. Usar el incorrecto no sólo es ineficaz: en algunos casos, simplemente no funciona.
La confusión es comprensible. Los tres "almacenan datos". Pero la distinción relevante no es lo que hacen en abstracto: sino cómo se desempeña cada uno bajo tráfico real, cuánto cuestan a escala y qué garantías ofrecen.
KV: el almacén global de datos pequeños y leídos con frecuencia
KV es un almacén de valores clave distribuido globalmente. Las escrituras van a un almacén central y se propagan a más de 300 PoP en hasta 60 segundos. Las lecturas llegan en menos de milisegundos si la clave está almacenada en caché en el PoP más cercano, o ~20 ms si es necesario recuperarla del almacén central.
El modelo de costos favorece las lecturas de volumen: 0,50 dólares por millón de lecturas después de los primeros 10 millones de lecturas mensuales gratuitas. Las escrituras cuestan lo mismo $0,50 por millón, pero con sólo 1 millón gratis. El límite máximo por valor es de 25 MB.
KV funciona bien para datos rara vez escritos y leídos masivamente: configuración de producto, indicadores de funciones, plantillas, índices de contenido, tokens de sesión con TTL. Funciona mal para cualquier cosa que cambie con frecuencia o requiera coherencia inmediata; la coherencia eventual con una ventana de hasta 60 segundos y la ausencia de operaciones atómicas son limitaciones reales, no detalles de la documentación.
R2: almacenamiento de objetos sin tarifa de salida
R2 es el almacenamiento de objetos de Cloudflare, equivalente funcional a S3. Fue creado para archivos grandes: imágenes, videos, copias de seguridad, exportaciones de datos, activos estáticos. La diferencia competitiva en relación con S3 es la ausencia de una tarifa de salida: no se paga por transferir datos desde R2 a Internet, que en S3 es una de las líneas más dolorosas de la factura.
El costo de almacenamiento es de $0,015/GB-mes. Cada operación de lectura (GET) en R2 cuenta como una solicitud; no hay un caché automático global como en KV. Si OBTIENE un objeto R2 en cada solicitud de Trabajador, está pagando por cada solicitud más el tiempo de latencia de cada GET. Esto hace que R2 no sea adecuado para datos de alta frecuencia de lectura por solicitud.
La combinación correcta es usar R2 para el archivo y KV (o Cache API) para el índice o la versión almacenada en caché. Un trabajador que proporciona imágenes puede almacenar el binario en R2 y mantener un JSON en KV con URL firmadas, metadatos y encabezados HTTP; por lo tanto, la lectura frecuente accede a KV en menos de milisegundos, y R2 solo se toca para cargar y generar URL.
El límite por objeto en R2 no es el mismo que en KV: se admiten archivos de varios GB. Para KV con su máximo de 25 MB por valor, R2 es el destino natural para cualquier dato que supere este umbral.
API de caché: el caché de respuesta HTTP por PoP
La API de caché almacena Response objetos en la caché HTTP del PoP actual. Es gratuito, no tiene cuotas de operación y funciona como una capa de almacenamiento en caché sobre las respuestas HTTP, no como un almacén de estado compartido.
El detalle crítico que lo diferencia de KV es el alcance: la API de caché es por PoP, no global. Un acierto de caché en el PoP de São Paulo no afecta al PoP de Frankfurt. Si un trabajador en Frankfurt nunca recibió una solicitud para esa URL, el caché estará frío en Frankfurt, independientemente de cuántas veces São Paulo entregó esa respuesta desde el caché.
Otro límite: el PoP puede expulsar el contenido de la API de caché en cualquier momento debido a la presión de la LRU. No hay garantía de persistencia entre solicitudes: la siguiente solicitud para el mismo recurso puede encontrar el caché frío, incluso si la solicitud anterior lo ha llenado.
La API de caché funciona bien para deduplicar solicitudes a API de terceros en un corto período de tiempo: la recupera una vez, almacena en caché Response durante 30 segundos y las solicitudes posteriores en el mismo PoP reutilizan la respuesta sin llamar a la API ascendente. También sirve para almacenar en caché respuestas computacionalmente costosas que se solicitan en ráfagas en el mismo PoP.
Lo que no funciona: usar Cache API como estado compartido entre trabajadores o entre regiones. Dos instancias de Worker en diferentes PoP no verán el mismo estado de caché. Para el estado compartido, KV es el camino.
La matriz anti-patrón
Usar R2 para la configuración de aplicaciones es el error más común entre los equipos que llegan de S3. En S3, es común almacenar config.json en un depósito y leerlo al iniciar la aplicación; el servidor dura horas o días, por lo que GET cada reinicio es económico. En Workers, cada aislamiento se puede crear y destruir con frecuencia. Cada GET a R2 tiene la latencia de una solicitud de red y cuenta como una operación cobrada. Para la configuración, KV con almacenamiento en caché a nivel de módulo es el modelo correcto.
Usar KV para archivos de video o grandes conjuntos de datos es el otro extremo. El límite de 25 MB por valor ya crea problemas inmediatos para cualquier activo de tamaño real. Pero más allá del límite, el costo de escribir en KV es prohibitivo para los archivos que llegan frecuentemente a través de la carga del usuario. R2 a 0,015 dólares/GB-mes es varios órdenes de magnitud más barato para el almacenamiento de archivos de gran tamaño.
El uso de Cache API para cualquier tipo de estado que deba ser coherente en todos los PoP es una fuente garantizada de comportamiento errático. El síntoma típico es un error que aparece "a veces", porque el PoP que atendió la solicitud anterior tenía el caché lleno y el PoP que atendió ésta no. La API de caché no reemplaza KV para datos globales.
Cómo elegir
La decisión comienza con el tipo de datos y la frecuencia de acceso. Los datos pequeños, leídos muchas veces por segundo, necesitan distribución global: KV. Archivo grande, escrito mediante carga y leído con frecuencia baja a moderada: R2. Respuesta HTTP que rara vez cambia y puede ser local de PoP: API de caché.
El coste confirma o descarta la elección. Si el volumen de escrituras es alto, KV se vuelve caro. Si el volumen de GET individuales por archivo es alto, R2 se vuelve costoso y lento. Si necesita coherencia entre PoP, la API de caché no funcionará.
Combinar los tres es el modelo correcto
El patrón que aparece con mayor frecuencia en arquitecturas maduras con Workers es una combinación deliberada. R2 almacena el binario. KV almacena el índice, los metadatos y la URL firmada de corta duración. La API de caché deduplica las solicitudes en ráfaga al mismo PoP. Cada capa hace aquello para lo que fue diseñada y el resultado es una pila de almacenamiento que funciona bien y cuesta lo que debería costar.
La trampa intenta simplificarse a una sola primitiva. Cloudflare ofrece los tres porque cada uno resuelve un problema diferente. Comprender el límite entre ellos es lo que separa una implementación que funciona en desarrollo de otra que sobrevive al tráfico real.
Lea también
- Cloudflare KV: ¿Qué significa distribuido globalmente cuando necesitas escribir?
- Invalidación de caché en KV: el problema que nadie soluciona elegantemente
- Balanceo de carga y dirección geográfica de Cloudflare: cuando DNS se convierte en una capa de tráfico inteligente
- KV en producción: los patrones que funcionan y los que engañan al principio
- [KV para limitación de velocidad, indicadores de funciones y configuración distribuida: dónde funciona y dónde falla7
- Trabajadores + D1 + KV + R2: componer vinculaciones en un mismo servicio