diff --git a/workloads/ecommerce/app/product/[slug]/page.tsx b/workloads/ecommerce/app/product/[slug]/page.tsx
index facb724..742569b 100644
--- a/workloads/ecommerce/app/product/[slug]/page.tsx
+++ b/workloads/ecommerce/app/product/[slug]/page.tsx
@@ -9,17 +9,17 @@ import { getProductBySlug, getProducts } from "@/lib/headless/client";
 
 interface ProductPageProps { params: Promise<{ slug: string }> }
 
-// Sin esto, la página queda estática para siempre con los datos del build
-// (que usa el catálogo mock porque HEADLESS_PROVIDER/MEDUSA_* no existen en
-// el contexto del Docker build). El listado sí se refresca porque su ruta
-// es dinámica por searchParams; esta ruta necesita el revalidate explícito
-// para que el runtime (que sí tiene las env vars de Medusa) la regenere.
-export const revalidate = 60;
-
-export async function generateStaticParams() {
-  const products = await getProducts();
-  return products.map((product) => ({ slug: product.slug }));
-}
+// generateStaticParams + revalidate quedaban aquí para pre-renderizar en
+// build time, pero HEADLESS_PROVIDER/MEDUSA_* no existen en el contexto del
+// Docker build: el snapshot estático quedaba congelado con el catálogo mock
+// (todos los productos con price: null) hasta que ISR lo revalidara. Con
+// frontend-deploy corriendo 2 réplicas y sin cacheHandler compartido, cada
+// pod revalida su propia caché de forma independiente, así que un producto
+// podía mostrar "Consultar precio" en un pod y el precio real en el otro
+// según cuál hubiera sido "calentado". force-dynamic elimina esa caché por
+// pod y deja esta ruta en vivo contra Medusa, igual que el listado
+// (dinámico por searchParams).
+export const dynamic = "force-dynamic";
 
 export async function generateMetadata({ params }: ProductPageProps): Promise<Metadata> {
   const { slug } = await params;