Miniaturas al subir o bajo demanda: manda la identidad duradera del activo

Procesar las miniaturas al subir o generarlas bajo demanda. La elección marca la latencia de la primera visita a una ficha de producto, y el criterio que se sostiene es doble: adelantar el trabajo cuando el escaparate necesita un primer render predecible, y hacerlo siempre como un trabajo idempotente con un identificador de activo duradero. Cuando la mayoría de las imágenes apenas se ven, o cuando la matriz de tamaños cambia cada pocos meses, conviene dejarlas para el momento de la lectura.

El criterio se enuncia en una frase y se mide fatal. Un cargador en React enseña la barra de progreso en segundos y la página de catálogo se queda esperando la variante de 320 píxeles, un navegador que envió un MIME que nadie verificó o un worker que reintentó y creó un segundo objeto en el bucket. Antes de fijar un valor por defecto hay que reproducir esos fallos: una semana de fotos reales, subidas con la concurrencia de una importación masiva de un vendedor, y comparar tiempo hasta la primera miniatura, tasa de acierto de derivados, bytes escritos y volumen de reprocesado.

La identidad va antes que el formato

El servidor debería asignar un identificador opaco en cuanto acepta una subida completa. Ese ID es la referencia estable para la aplicación, las filas del catálogo, los registros de moderación y los trabajos de derivados; la clave del objeto puede cambiar, el identificador no. A su lado se guardan el tamaño en bytes del original, las dimensiones medidas, el tipo de contenido, el checksum, el inquilino y el estado del procesado. La propiedad de esos bytes no se deduce nunca del nombre de fichero que manda el navegador.

Un estado sencillo —recibido, en proceso, listo, rechazado— basta. Una petición duplicada con la misma clave de idempotencia devuelve el ID original en lugar de crear un segundo objeto. Los reintentos del worker son seguros porque cada clave de derivado incluye el ID del activo, el ancho y la versión de la receta. Y el tipo declarado es solo una pista: el decodificador tiene que confirmar los bytes y las dimensiones. La guía de formatos multimedia de MDN sirve como referencia de compatibilidad, pero la matriz de navegadores que soportas es el examen final.

Lo que cuesta adelantar el trabajo

Generar al subir compra un camino de lectura predecible: las variantes de 320, 640 y 1280 ya están programadas y la página no paga la penalización de una transformación en frío. El precio es la amplificación de escritura, porque cada imagen puede producir tres objetos aunque nadie abra la ficha. El trabajo bajo demanda invierte el trato: mantiene el almacenamiento ajustado en el catálogo largo, pero el primer visitante paga la cola y la transformación, y hace falta una política contra estampidas de caché para que diez peticiones simultáneas converjan en un único trabajo en lugar de encolar diez idénticos.

Lo medible aquí son dos cosas: la latencia p95 de la primera miniatura y el porcentaje de variantes que nadie lee en 30 días. Si el ratio de variantes muertas domina, ese ancho se mueve a bajo demanda. Una restricción de unicidad en base de datos sobre (asset_id, receta, ancho) es el último guardián contra duplicados, y un timeout debe dejar el estado recuperable en vez de obligar a adivinar si los bytes llegaron a escribirse. El caso que rompe todo esto es un fichero de 12 MB, un PNG con extensión JPEG, un vendedor que pulsa enviar dos veces y un worker que se reinicia entre la escritura del original y la transición a listo.

La diferencia entre un billete de soporte y una traza reproducible está en si el sistema puede demostrar qué ID posee esos bytes y qué receta produjo ese derivado. Lo que queda por ver es qué ancho concreto sale caro en cada catálogo.