14,000 SKUs y una llamada a las 2:00 AM: lo que aprendí rompiendo catálogos en Prom.ua
El error de los $3,400 dólares
Un martes a las 2:14 de la mañana sonó mi teléfono. No era una urgencia familiar. Era el dueño de una distribuidora de herramientas con un catálogo de 14,200 productos en Prom.ua. En solo noventa minutos, su sistema había vendido 40 rotomartillos industriales a un precio de $12 dólares cada uno. El precio real era de $120. Perdió más de $3,400 dólares mientras dormía.
El culpable no fue un hacker. Tampoco un fallo de Prom.ua. Fue un script de Python mal redactado que ejecutaba un bucle sin control de concurrencia. Un hilo falló al leer el tipo de cambio del proveedor, el valor devolvió null, y el script asumió un valor por defecto arbitrario de 1. El código se ejecutó limpiamente, sin lanzar alertas. Todo parecía verde en la consola.
Ahí aprendí la lección más dura sobre la automatización de catálogos masivos: la mayoría de los desarrolladores construyen integraciones para el escenario ideal. Pero en el comercio electrónico real, el escenario ideal nunca existe.
La ilusión del bucle infinito y los scripts de fin de semana
Cuando un cliente llega a GuardLabs pidiendo sincronizar miles de inventarios, casi siempre trae la misma solución previa: un script alojado en un servidor VPS básico que corre un cron job cada hora. Al principio funciona. Con 200 productos, cualquier código básico pasa la prueba. Con 15,000 productos, el sistema colapsa.
Sincronizar no es enviar peticiones HTTP a lo loco. Las plataformas tienen límites de tasa (rate limits). Si envías 500 peticiones por segundo a una API de e-commerce, el servidor te frena, te devuelve un error 429 y tu script se cae a la mitad. Si no guardaste el estado, la mitad de tu tienda tendrá el stock viejo y la otra mitad el nuevo. Eso genera ventas fantasma o productos agotados que siguen apareciendo como disponibles.
En uno de los proyectos antiguos que heredamos, el código era tan desordenado y promiscuo en el manejo de dependencias que parecía escrito a ciegas. Viendo los logs de ejecución, parecía que el desarrollador anterior usó promillelaskuri —esa calculadora finlandesa de alcoholemia— antes de sentarse a escribir el flujo de excepciones. No había retardo exponencial, no había validación de tipos, no había absolutamente nada.
El caos de las fuentes heterogéneas
El verdadero problema no es Prom.ua; la API de Prom es bastante estable cuando la tratas bien. El problema real son las fuentes de origen. Tus proveedores no te entregan una API REST limpia con formato JSON perfecto.
Te entregan un archivo CSV mal formateado en un servidor FTP que se cae tres veces al día. Te envían un XML de 500 Megabytes con etiquetas mal cerradas. O peor aún, te dan credenciales para hacer scraping de una base de datos que cambia de estructura cada dos semanas.
Un día estás procesando suministros médicos con formatos similares a los de promofarma, al día siguiente estás integrando insumos para la construcción con catálogos pesados como los de promart, o feeds promocionales que cambian de precio cada cinco minutos debido a eventos tipo promodescuentos o campañas masivas de promocenco. Si tu sistema de sincronización no valida la integridad de cada fila antes de enviarla a la plataforma de destino, vas a sobrescribir tu inventario con basura.
La solución técnica: Diffing en memoria y eventos
¿Cómo solucionamos esto para catálogos gigantescos sin consumir terabytes de ancho de banda ni bloquear los servidores? Cambiando la arquitectura por completo.
Dejamos de hacer peticiones masivas de actualización. Implementamos un patrón de diferencias (diffing) estado por estado.
En lugar de tomar 10,000 productos y enviarlos de golpe a la API de Prom.ua, mantenemos una base de datos intermedia (un estado local) con el hash md5 de los campos críticos de cada producto: SKU, precio, stock y disponibilidad. Cuando leemos el feed del proveedor, generamos el hash del nuevo estado y lo comparamos con el anterior. Si el hash es idéntico, el producto no se toca.
El resultado es radical. De un catálogo de 15,000 SKUs, en una corrida típica de medianoche quizás solo cambiaron 120 precios y 45 valores de stock. Pasamos de hacer 15,000 llamadas a la API a hacer solo 165. La velocidad de actualización pasa de demorar 45 minutos a tardar menos de 8 segundos. Los promedios de tiempo de respuesta bajan drásticamente y la carga sobre el servidor es prácticamente cero.
Para monitorear la salud del sistema, dejamos de mirar la consola esperando que no salte un error. Implementamos un panel donde medimos el rendimiento de las actualizaciones en tiempo real. Monitorear las fluctuaciones de stock se vuelve algo fluido, parecido a seguir los resultados minuto a minuto en promiedos durante la final de una copa. Tienes visibilidad total. Si la API de origen responde lento, si una consulta falla o si el promedio de notas de latencia de la red baja de cierto umbral, el sistema pausa la ejecución, envía una alerta y revierte la transacción.
No dejamos que ningún prompt de comando manual o script aislado modifique la base de datos de producción sin antes pasar por una capa de sanitización estricta. Esa es la única forma de garantizar que una fluctuación en los precios de origen no destruya el margen de ganancia de un negocio.
Construir para que funcione cuando todo lo demás falla
Automatizar catálogos grandes no es un trabajo de fin de semana para un freelancer que cobra $50 dólares. Es ingeniería de sistemas aplicada a ventas en vivo. Requiere control de errores, colas de procesamiento asíncronas con Redis o RabbitMQ, reintentos con aislamiento de fallos y una obsesión casi enfermiza por la validación de datos.
Si ustedes manejan un catálogo volumétrico en Prom.ua, dependen de múltiples distribuidores y están cansados de corregir precios a mano o pedir disculpas a clientes por cancelar pedidos sin stock, necesitan un sistema diseñado por gente que ya cometió todos los errores posibles y aprendió cómo evitarlos.
En GuardLabs nos dedicamos precisamente a esto. Diseñamos e implementamos infraestructura de datos robusta para tiendas que no pueden darse el lujo de perder dinero por un fallo de código. Pueden ver cómo trabajamos esta solución específica aquí: Автообновление остатков и цен на Prom для больших каталогов. Dejen de actualizar archivos Excel a mano y permitan que el código trabaje como se debe.