El infierno de sincronizar 40,000 productos y por qué los scripts simples siempre revientan

Eran las 3:18 de la madrugada de un martes cuando mi teléfono empezó a vibrar como si tuviera vida propia. Un cliente que vende autopartes en Prom.ua acababa de vender cuatro transmisiones completas a precio de remate: 180 dólares cada una, cuando el costo del proveedor rozaba los 920 dólares. Pérdida neta instantánea de casi tres mil dólares antes del amanecer. ¿El culpable? Un script barato en Python que alguien montó en un VPS de tres dólares, un proveedor que cambió sin avisar la cabecera de su archivo CSV y una sincronización ciega que interpretó una columna vacía como descuento masivo.

Todo el mundo cree que sincronizar inventario es un juego de niños. "Lees un archivo XML, llamas a una API y listo". Falso. Eso funciona cuando vendes veinte tazas de cerámica. Cuando gestionas 30,000, 60,000 o 100,000 SKUs repartidos entre tres distribuidores distintos que actualizan sus existencias a horas absurdas, el problema deja de ser técnico y se vuelve operativo, financiero y psicológico.

La trampa del script optimista

Al principio, casi todos los comercios caen en la misma trampa. Contratan a alguien para que arme un script rápido. Durante dos semanas todo parece una promesa brillante, una historia con final feliz al estilo promising young woman antes del giro oscuro. El tablero muestra verde, los productos suben y las ventas entran. Pero el comercio electrónico a gran escala no perdona el optimismo ingenuo.

Un distribuidor decide renombrar la columna "stock_disponible" por "existencias". Otro cambia el formato de moneda de UAH a EUR sin un solo aviso en el feed. El script falla a mitad del proceso por un límite de tasa (rate limit) de la API de Prom, se corta en el producto número 14,200 y deja los siguientes 25,000 SKUs con precios congelados desde hace cuatro días. Mientras el dueño duerme o se distrae mirando los marcadores de fútbol en Promiedos durante el fin de semana, su catálogo está vendiendo mercancía que ya no existe en bodega.

Creer que esto se soluciona tirándole un prompt a un modelo de lenguaje para que te escriba un webhook nuevo es subestimar la suciedad de los datos reales. La inteligencia artificial escribe código bonito; la realidad de los almacenes es brutalmente caótica.

Los números no mienten: la latencia destruye márgenes

Hagamos matemáticas simples. Si manejas 45,000 productos y tu proceso de sincronización tarda cuatro horas en recorrer todo el catálogo, tu ventana de riesgo es de 240 minutos por ciclo. Si calculas los promedios de rotación de un catálogo pesado, descubrirás que en cuatro horas un proveedor mayorista agota docenas de líneas clave. Vendes aire.

En el comercio minorista gigantesco, una cadena como Promart puede absorber ciertos márgenes de error porque controlan su propia cadena física. En marketplaces verticales como PromoFarma en salud o Promod en el sector textil, las reglas de abastecimiento son hiperespecíficas y cerradas. Pero Prom.ua es la jungla abierta. Si cancelas tres pedidos seguidos por falta de existencias, tu calificación de vendedor se desploma y el algoritmo de la plataforma te entierra en la página ocho de resultados.

El estrés que esto genera en los equipos de operaciones no es broma. He visto fundadores al borde del colapso nervioso, bromeando con que necesitan una dosis de promethazin solo para poder apagar la pantalla sin miedo a despertar en bancarrota.

Cómo construimos tuberías que no se rompen a las 3 AM

En GuardLabs aprendimos esto a base de cicatrices y noches en vela. Con los años desechamos la idea del "script que corre y reza". Para mantener catálogos masivos vivos en Prom.ua sin intervención humana, la arquitectura tiene que ser defensiva por diseño:

Primero: idempotencia y sincronización delta. Jamás intentamos actualizar 50,000 registros de golpe si solo cambiaron 400. Nuestro motor calcula diferencias criptográficas (hashes) por cada SKU. Si el precio y el stock no se movieron, la API de Prom ni siquiera se toca. Reducimos el tráfico en un 90% y esquivamos los bloqueos de tasa como si nada.

Segundo: cuarentena de datos automática. Si un proveedor publica un feed donde el 20% de los precios cae a cero o cambia drásticamente respecto al día anterior, el sistema no actualiza a ciegas. Bloquea el lote, levanta una alerta y mantiene el último estado seguro en la tienda. Como el mito de Prometeo trayendo el fuego a los mortales: la automatización debe iluminar el negocio, no quemarlo hasta los cimientos por falta de control.

Tercero: telemetría real. Montamos métricas continuas con herramientas como Prometheus para vigilar tiempos de respuesta de la API, fallos de red en los servidores mayoristas y colas de procesamiento. Si un conector tose, nos enteramos antes de que el cliente final haga clic en "comprar".

Dejar de teclear a mano para empezar a escalar

El trabajo manual de ajustar precios con hojas de cálculo compartidas no escala. Es una condena lenta que le roba el tiempo a su equipo y garantiza que cometan errores humanos costosos cada semana. Su trabajo debería ser negociar con distribuidores y cerrar ventas, no revisar filas en Excel a las diez de la noche.

Si maneja miles de referencias en el mercado ucraniano y está cansado de lidiar con cancelaciones por falta de stock o pérdidas por variaciones cambiarias que nadie cargó a tiempo, podemos resolverlo de raíz con nuestra infraestructura dedicada: Автообновление остатков и цен на Prom для больших каталогов. Configuramos el flujo, blindamos las reglas de sincronización y dejamos que el sistema trabaje en silencio mientras ustedes se concentran en vender.