El mismo secreto que usa el gateway. No se guarda en el servidor.
Posición en el carrusel. 1 es la portada, la que sale en la grilla. El manifiesto dice cuántas hay.
Quién pide la imagen: el aliado o la app. Define su tier y a qué promociones entra. No cambia la imagen, cambia el trato.
Para qué la quieres, no cuántos píxeles. El front pide card, no w=400. Así cambiar de proveedor no toca el front.
CO o VE. El mismo SKU puede tener imagen distinta por país.
El SKU del producto, tal cual sale de Algolia. Sin rutas internas, sin nombres de bucket, sin hashes.
Un solo <img>. El navegador elige la densidad; el gateway
elige el formato (AVIF, WebP o JPEG) leyendo el Accept. El front no decide nada de eso.
Un componente que recibe sku y preset. Cambiar de
proveedor, de formato o de calidad no toca este archivo.
zoom: el catálogo actual es de 512×512. Un preset de 1800 px
no tiene píxeles de dónde salir, así que devuelve 512 y la lupa no amplía nada. Para que
zoom signifique algo hacen falta masters mayores de los aliados.
Una campaña activa fuerza el backend Cloudinary, porque es el único que compone capas. Gana al tier y al reparto A/B: una insignia de descuento es un compromiso comercial, no una preferencia de rendimiento. Si Cloudinary está apagado, no hay promo y se dice — nunca se sirve la imagen sin insignia fingiendo que sí.
En thumb (120 px) una insignia es ilegible.
Lo normal es solo la 1: la grilla enseña la portada, así que ahí va la insignia y las fotos de detalle se quedan limpias. Las posiciones no marcadas siguen el enrutado normal, sin pasar por Cloudinary.
El gateway cachea la config 5 s en cada isolate: un cambio se propaga muy por debajo del objetivo de 60 s del §8. Subir la versión de caché invalida todo sin purgar.
El reparto es hash(tenant + ruta) % 100, no azar por petición: cada imagen cae siempre en el mismo backend. Con reparto aleatorio las dos ramas medirían la misma imagen y el cache hit ratio sería ruido. Muestra de 300 productos.
| tenant | backend | motivo | bytes |
|---|