diff --git a/workloads/ecommerce/lib/headless/providers/medusa.ts b/workloads/ecommerce/lib/headless/providers/medusa.ts
index 790779c..a1cb9e2 100644
--- a/workloads/ecommerce/lib/headless/providers/medusa.ts
+++ b/workloads/ecommerce/lib/headless/providers/medusa.ts
@@ -111,14 +111,26 @@ async function medusaFetch<T>(
 
   const publishableKey = process.env.MEDUSA_PUBLISHABLE_KEY;
 
+  // Sin next.revalidate/tags a proposito (reportado por el usuario
+  // 2026-09-20: imagenes editadas a mano en Medusa no se reflejaban en
+  // el storefront, pero por CSV si). Causa real: frontend-deploy corre 2
+  // replicas sin cacheHandler compartido -- cada pod tenia su propio
+  // cache en memoria de este fetch (next.revalidate:60), y el POST de
+  // /api/revalidate (revalidateTag) del subscriber de Medusa solo le
+  // llegaba a UNO de los dos pods via el Service, dejando al otro
+  // sirviendo la respuesta vieja hasta que el TTL expirara solo. Una
+  // edicion puntual + revisar al toque tenia ~50% de chance de pegarle
+  // al pod stale; una importacion CSV (minutos de duracion) le daba
+  // tiempo de sobra al TTL para expirar en ambos pods, disimulando el
+  // mismo bug. Las paginas que consumen esto ya son force-dynamic /
+  // dinamicas por diseño (ver comentario en app/page.tsx y
+  // app/product/[slug]/page.tsx) -- este next.revalidate competia contra
+  // esa intencion en vez de cumplirla. Sin este bloque, Next 15 no
+  // cachea el fetch por default dentro de una ruta dinamica.
   const response = await fetch(url, {
     headers: publishableKey
       ? { "x-publishable-api-key": publishableKey }
       : undefined,
-    next: {
-      revalidate: 60,
-      tags: ["medusa-products"],
-    },
   });
 
   if (!response.ok) {