Cloudflare Workers suma caché nativa para apps edge

Cloudflare acaba de mover una pieza que, para muchos equipos, estaba faltando en la capa edge: una caché pensada para Workers. No hablamos de una idea abstracta ni de una optimización menor. Hablamos de una forma más directa de guardar y reutilizar respuestas cerca del usuario, sin obligarte a montar tu propia estrategia de almacenamiento temporal fuera del runtime.

Si estás construyendo una app edge-first, esto importa por dos razones muy concretas: menos latencia y menos costo. Menos latencia porque puedes evitar recomputar o volver a pedir datos en cada request. Menos costo porque reduces trabajo repetido en Workers y también presión sobre orígenes, APIs externas o bases de datos. En la práctica, eso te da más margen para servir tráfico real sin pagar cada vez el precio completo del cómputo.

Qué cambia con Workers Cache

Hasta ahora, cuando pensabas en caché dentro del ecosistema de Cloudflare, lo normal era usar patrones conocidos de HTTP caching, Cache API o incluso construir una estrategia alrededor de KV, Durable Objects o un backend externo. El problema no era la falta de herramientas, sino la fricción de unirlas bien. Si tu Worker hacía de orquestador, cada request podía terminar repitiendo trabajo que ya habías resuelto segundos antes.

Workers Cache apunta justo a ese hueco. La idea es que el runtime tenga una capa de caché más natural para los casos donde tu Worker genera o transforma respuestas y quieres reutilizarlas sin salirte del borde. En vez de pensar solo en “cómo respondo rápido hoy”, piensas en “cómo respondo rápido la próxima vez, desde el mismo punto de ejecución”.

La documentación y el anuncio oficial de Cloudflare explican el enfoque desde el lado del producto: una caché nativa para Workers, diseñada para encajar con el modelo edge. Puedes revisar la fuente original aquí: Workers Cache. Para quien desarrolla aplicaciones con tráfico repetitivo, eso abre un patrón muy útil: cachear resultados de lógica de negocio, no solo assets estáticos.

Por qué esto no es solo otra caché

Una CDN tradicional suele brillar con archivos estáticos, HTML público o respuestas relativamente predecibles. Pero una app moderna en edge no vive solo de eso. Tienes personalización parcial, consultas a APIs, validación por headers, variantes por país, idioma o segmento, y muchas veces un mismo request puede resolverse con lógica pesada antes de devolver algo simple.

Ahí es donde una caché nativa para Workers encaja mejor. No necesitas mover toda la app a un modelo rígido de reverse proxy. Puedes mantener lógica en el Worker y almacenar el resultado de esa lógica cuando tenga sentido. El beneficio real no es solo “guardar respuestas”, sino evitar recomputar decisiones que ya tomaste.

También cambia el costo operativo. Si una respuesta se sirve desde caché en el edge, reduces invocaciones que terminan en fetchs a origen, consultas a terceros o transformaciones costosas. Para equipos en LatAm, donde a veces el margen está más apretado y el tráfico internacional encarece la operación, eso no es un detalle menor.

Cómo encaja en una arquitectura edge-first

Si ya usas Workers como capa de entrada, probablemente tu arquitectura se parezca a esto: el request entra, el Worker decide si responde de inmediato, consulta una API, arma una respuesta y devuelve el resultado. El cuello de botella aparece cuando esa lógica se repite cientos o miles de veces por minuto para el mismo recurso o para recursos muy parecidos.

Workers Cache te permite mover parte de esa repetición fuera del camino crítico. Eso cambia el diseño de la app. Ya no piensas solo en “cómo hago el fetch”, sino en “qué parte de esta respuesta puede vivir unos segundos o unos minutos sin romper la experiencia”.

Un ejemplo realista: una tienda online con catálogo por país. El precio base puede venir del backend, pero el HTML final depende de moneda, impuestos, disponibilidad y promociones. Si cada visita recalcula todo, el costo sube rápido. Si cacheas la variante correcta por país y segmento, puedes servir una página lista en el borde y reservar el backend para cuando de verdad cambie algo.

Qué tipo de respuestas suelen beneficiarse

No todo debe ir a caché. Eso ya lo sabes, pero en edge la tentación de cachear todo puede salir cara si no separas bien lo estático de lo sensible. Donde sí suele rendir es en respuestas con estas características:

• Se repiten mucho en un rango corto de tiempo.
• Dependen de pocas variables controlables, como país, idioma o plan.
• Tardan más en generarse que en leerse.
• Tienen tolerancia a una pequeña ventana de staleness.

Un blog con tráfico alto, una página de producto, un endpoint de configuración pública, un feed de contenido o una respuesta agregada de varias APIs son candidatos típicos. En cambio, datos de sesión, carritos, permisos o información personal deben tratarse con más cuidado o directamente fuera de caché.

Dónde te ahorra más latencia

La mayor ganancia no siempre viene de “un request menos” sino de cortar saltos geográficos. Si tu usuario está en Quito, Lima o Medellín y tu backend está en otra región, cada ida y vuelta suma. Con una caché en el edge, muchas respuestas se resuelven en la misma zona donde entra el tráfico.

Eso puede recortar tiempos de forma visible en páginas con contenido repetido. No hace falta prometer números mágicos para entender el beneficio: menos viajes al origen casi siempre significa menos espera. Y si tu Worker además hace transformaciones, el ahorro se multiplica porque también eliminas cómputo repetido.

Qué deberías revisar antes de adoptarla

Antes de meter Workers Cache en producción, conviene revisar tres cosas: el patrón de acceso, la granularidad de la clave y la política de invalidación. Si fallas en una de esas, una caché rápida solo te entrega respuestas equivocadas más rápido.

Primero, define qué porcentaje de tus requests son repetidos. Si tu endpoint cambia en cada llamada, cachear no ayuda. Si el 70% o más de las solicitudes repiten el mismo patrón de entrada, ya tienes una señal fuerte. Segundo, decide qué entra en la cache key: URL, query params, headers, país, idioma, plan, A/B bucket. Tercero, define cuándo expira o se invalida el contenido.

Aquí te sirve pensar como producto, no solo como backend. Una página de inventario puede tolerar 30 segundos de retraso. Un precio promocional quizá no. Un dashboard interno puede aceptar 1 minuto. Una respuesta de autenticación, no. La caché no es buena ni mala por sí misma, depende de la tolerancia al cambio.

Señales de que sí te conviene

Hay casos donde la decisión es bastante clara. Si reconoces varios de estos puntos, Workers Cache puede darte retorno rápido:

1. Tu Worker hace fetch a una API lenta o con rate limits.
2. Tu app tiene usuarios distribuidos en varios países.
3. Repetís transformaciones de HTML, JSON o headers en cada request.
4. Tu backend ya sufre picos por tráfico repetido.
5. Tu equipo quiere bajar costo sin reescribir toda la arquitectura.

En cambio, si casi todo es personalizado por usuario y cambia en cada request, el valor baja. Ahí la caché puede seguir siendo útil para fragmentos públicos o para datos compartidos, pero no como estrategia principal.

Ejemplo práctico de implementación

Cloudflare no te pide abandonar tu lógica actual. La idea es que puedas decidir, dentro del Worker, si una respuesta puede servirse desde caché o si toca regenerarla. En términos de diseño, eso te deja un patrón bastante limpio: intentas leer, si hay hit respondes, si no hay hit calculas y guardas.

Un flujo simple se vería así:

export default {
  async fetch(request: Request, env: Env, ctx: ExecutionContext): Promise<Response> {
    const cache = caches.default;
    const cacheKey = new Request(request.url, request);

    const cached = await cache.match(cacheKey);
    if (cached) {
      return cached;
    }

    const originResponse = await fetch(request);
    const response = new Response(originResponse.body, originResponse);
    response.headers.set("Cache-Control", "public, max-age=60");

    ctx.waitUntil(cache.put(cacheKey, response.clone()));
    return response;
  }
}

Este ejemplo es intencionalmente simple, porque lo importante no es copiarlo tal cual sino entender el patrón. Primero buscas en caché. Luego generas la respuesta. Después la guardas para la próxima vez. Si tu caso requiere normalizar query params, variar por país o excluir cookies, esa lógica va antes de construir la clave.

Buenas prácticas para no romperte después

Hay varios detalles que conviene cuidar desde el inicio:

• No uses la URL cruda si tiene parámetros que no afectan la respuesta.
• Separa contenido público de contenido privado.
• Define TTL cortos al principio y mide hit ratio antes de subirlos.
• Evita cachear respuestas con cookies de sesión o headers sensibles.
• Usa una estrategia de invalidación clara para cambios de catálogo, precios o contenido editorial.

Si tu equipo ya trabaja con Cache API, el cambio mental no es enorme, pero sí cambia el lugar donde piensas la caché. No la ves como un accesorio al final del pipeline, sino como parte del diseño del Worker.

Impacto en costo y operación

Cuando se habla de edge, muchas veces se piensa solo en velocidad. Pero el costo operativo también pesa. Cada request que no llega al origen es una oportunidad de ahorrar ancho de banda, CPU, consultas a base de datos y llamadas a proveedores externos. Si además el Worker evita recomputar lógica, el ahorro se duplica.

No hace falta exagerar para ver el efecto. Imagina un endpoint con 10.000 requests por hora y una tasa de hit de 80%. Eso significa que 8.000 requests ya no pasan por el camino completo. Si cada respuesta implicaba varias consultas o una transformación pesada, el impacto económico puede ser bastante claro en la factura mensual.

En LatAm esto importa aún más porque muchas veces el stack no está distribuido de forma ideal. Tienes usuarios en varios países, pero el backend vive en una sola región. Cada salto internacional agrega latencia y puede subir el costo de salida de datos. Una caché en Workers ayuda a amortiguar ese problema sin obligarte a mover todo de una vez.

Cómo medir si te está funcionando

No te quedes solo con la intuición. Mide al menos estas métricas:

• Cache hit ratio por endpoint.
• Latencia p50 y p95 antes y después.
• Número de fetchs al origen por minuto.
• Costo por request servido desde Worker.
• Errores por respuestas stale o mal cacheadas.

Si el hit ratio sube pero tu p95 no mejora, probablemente la clave está mal armada o estás cacheando poco tiempo. Si el costo baja pero aparecen bugs de consistencia, la invalidación está demasiado agresiva o demasiado laxa. El valor real aparece cuando mejoras dos cosas a la vez: velocidad y confiabilidad.

Tabla resumen

Si quieres profundizar en el funcionamiento del runtime y las opciones de caché disponibles, también te conviene revisar la documentación oficial de Cloudflare sobre Workers y Cache API: Cloudflare Workers docs y Cache API. Ahí vas a encontrar el contexto técnico para adaptar este patrón a tu caso.

Qué significa esto para equipos en LatAm

Para equipos en Latinoamérica, esta novedad tiene una lectura práctica: puedes acercar más tu lógica al usuario sin sumar tanta complejidad operativa. No necesitas una infraestructura enorme para empezar a sentir la mejora. A veces basta con identificar 2 o 3 endpoints caros y darles una capa de caché bien pensada.

También ayuda a equipos pequeños que no tienen una plataforma de datos sofisticada. Si tu app depende de un CMS, un ERP o varias APIs externas, una caché en Workers puede funcionar como amortiguador. No reemplaza tu backend, pero sí te da espacio para responder mejor cuando el tráfico sube o cuando una fuente externa se pone lenta.

En mercados donde el costo por infraestructura se revisa cada mes, esto es útil porque te deja optimizar antes de escalar equipo o reescribir servicios. Y si trabajas con usuarios repartidos entre México, Colombia, Perú, Ecuador, Chile o Argentina, la reducción de latencia se nota más de lo que parece en un gráfico.

La decisión correcta no es cachear todo

La tentación siempre es la misma: si existe una caché nueva, úsala en todo. Pero una arquitectura edge-first sana no trata la caché como atajo universal. La trata como una herramienta para seleccionar qué parte del trabajo merece repetirse y cuál no.

Si tu equipo define bien las claves, los TTL y la invalidación, Workers Cache puede convertirse en una pieza central de tu diseño. Si no, solo vas a mover complejidad de lugar. La diferencia está en la disciplina con la que modelas tus respuestas.

Tabla resumen