Un directivo decide conectar su robusto ERP SQL a internet. En un rapto de "eficiencia", pide que TODAS las fotos HD de sus miles de productos se inserten como campos BLOB dentro de la base de datos del ERP. Seis meses después, los backups del ERP tardan 14 horas, el sistema se traba y las fotos en la web se ven lentas.
Anti-Patrones de Arquitectura Media
Un sistema financiero (ERP) no está diseñado para traficar imágenes de 3 Megabytes. Su trabajo es procesar asientos contables y facturas en kilobytes. Obligarlo a oficiar de servidor de imágenes (Image Server) destruye la performance corporativa y enoja al sector de Sistemas (IT).
La Desacoplamiento (Decoupling)
La regla de oro B2B: "Datos por un lado, Pixeles por otro".
Paso 1: El Repositorio S3 / CDN
Todas las imágenes se suben a un bucket en la nube diseñado exclusivamente para eso (ej: Amazon S3). Cada imagen se nombra estrictamente con la lógica de SKU: CABLE-50MM-FOTO1.webp.
Paso 2: El Middleware Ligero
El sincronizador lee el ERP. Extrae: SKU: `CABLE-50MM`, Precio: `$5.000`, Stock: `500`. Y lo inyecta a la plataforma (Shopify/CommerceUp/VTEX).
Paso 3: El Ensamblaje en la Plataforma
El ecommerce, que ya recibió los datos del ERP, corre un microservicio en la nube que toma el SKU, se asoma al CDN de Amazon, y pregunta: "¿Hay alguna imagen que se llame CABLE-50MM?". Al encontrarla, las vincula internamente en su propia base de datos rápida, generando múltiples tamaños y versiones WebP amigables para Google (SEO).
Esta arquitectura garantiza una carga de web en menos de 1.5 segundos, y el ERP de la empresa ni se entera de que existen imágenes en el mundo.
