Tiempo estimado de lectura: 9 minutos
Conectar tu tienda online en WooCommerce o Shopify con tu ERP Odoo parece una decisión puramente operativa: compras un módulo conector en el mercado, introduces las credenciales de la API y esperas a que los pedidos y el stock fluyan en tiempo real. Y durante los primeros meses, cuando el volumen de pedidos es moderado, el sistema aguanta.
El problema estalla cuando escalas. De repente, lanzas una campaña agresiva de Paid Media, entras en pleno pico de Black Friday o tu equipo de almacén actualiza una tarifa de 5.000 referencias en el ERP. En ese instante, el checkout de tu e-commerce empieza a tardar 12 segundos en procesar el pago, aparecen errores 502 Bad Gateway, los pedidos se duplican o se quedan en el limbo, y tu equipo interno te avisa de que Odoo se ha quedado completamente congelado.
La causa rara vez es la potencia bruta de tu servidor; el culpable es una arquitectura de integración síncrona que ignora cómo gestiona Odoo sus procesos internos. En este artículo analizamos por qué fracasan los conectores comerciales estándar bajo presión y cómo estructurar un sistema de sincronización asíncrono capaz de absorber picos de tráfico sin despeinarse.
La anatomía del colapso: ¿Por qué un pico de tráfico en tu web tumba tu ERP?
Para entender por qué tu tienda online puede asfixiar a tu ERP, hay que bajar al capó de la infraestructura de Odoo y del protocolo de comunicación que utilizan el 95% de los plugins del mercado.
1. El límite físico de los Workers en Odoo
Odoo opera mediante un sistema de procesos llamados workers (calculados habitualmente en función de los núcleos de CPU y la memoria RAM del servidor). Cada worker es capaz de gestionar una única petición simultánea.
Si tu instancia de Odoo tiene configurados 6 workers HTTP, significa que solo puede procesar 6 acciones exactamente en el mismo milisegundo. Si en el segundo 1 entran 4 clientes pagando en WooCommerce —cuyo plugin lanza una petición inmediata a Odoo para crear la orden de venta (sale.order) y descontar stock— y al mismo tiempo tienes a 3 operarios en el almacén validando albaranes con pistolas de radiofrecuencia, ya has saturado la capacidad de concurrencia del sistema. La séptima petición entra en cola; si la cola supera el tiempo de espera (timeout), la conexión muere.
2. El acoplamiento síncrono en el Checkout
El error de diseño más grave de los conectores tradicionales para WooCommerce y Shopify es ejecutar la llamada a la API de Odoo dentro del hilo de ejecución del checkout del cliente.
Cuando el usuario hace clic en «Pagar», la web intenta comunicarse con Odoo vía XML-RPC o JSON-RPC para verificar el cliente (res.partner), crear el pedido y reservar el inventario antes de mostrar la página de agradecimiento (Thank You Page). Si el ERP tarda 4 segundos en responder porque está recalculando costes de inventario, tu cliente sufre esos 4 segundos de pantalla en blanco. Si tarda 30 segundos, el navegador corta la conexión: el cobro en Stripe o Redsys se ha ejecutado, pero el pedido jamás llega a Odoo.
3. Bloqueos en base de datos (PostgreSQL Serialization Failures)
Cuando múltiples llamadas de API intentan modificar el mismo registro al mismo tiempo —por ejemplo, 15 usuarios comprando el mismo producto estrella en promoción—, PostgreSQL protege la integridad de los datos bloqueando las filas afectadas (row-level locking). Las llamadas concurrentes chocan contra el error psycopg2.extensions.TransactionRollbackError: could not serialize access due to concurrent update, provocando reintentos en bucle que terminan de agotar los workers disponibles.
Arquitectura síncrona (Plugin Estándar) vs. Arquitectura Desacoplada
Para visualizar el impacto en el rendimiento y en el negocio, comparamos el comportamiento de un conector directo frente a una infraestructura mediada por colas de mensajes (Message Brokers).
| Vector Operativo | Conector Directo / Plugin Estándar (Síncrono) | Arquitectura con Middleware y Colas (Asíncrona) |
| Impacto en velocidad del Checkout | Alto: El cliente espera a que Odoo responda para ver su confirmación. | Nulo (0 ms): El e-commerce registra la venta y delega el envío en segundo plano. |
| Tolerancia a caídas de Odoo | Crítica: Si Odoo entra en mantenimiento o se cae, se pierden pedidos o falla el checkout. | Total: Los pedidos se almacenan en la cola y se inyectan automáticamente cuando Odoo vuelve a estar online. |
| Consumo de Workers en ERP | Descontrolado: Los picos de tráfico web secuestran los recursos del equipo interno. | Regulado (Throttling): El middleware inyecta datos a un ritmo constante (ej. 2 peticiones/segundo). |
| Actualización masiva de catálogo | Bloqueos frecuentes: Timeouts por exceso de payload al actualizar miles de SKUs. | Fluida: Procesamiento por lotes (batching) y actualización diferencial solo de campos modificados. |
| Trazabilidad de errores | Opaca: Logs enterrados en el servidor web difíciles de auditar. | Centralizada: Panel visual con alertas en tiempo real y reintentos automáticos (Exponential Backoff). |
Cómo diseñar una integración inmune a caídas en 4 capas
Para eliminar el cuello de botella sin multiplicar por diez tu factura de servidores en AWS, Google Cloud u Odoo.sh, debemos aplicar el principio fundamental de la ingeniería de sistemas modernos: desacoplar el canal de captación (E-commerce) del motor de gestión (ERP).
1. Sustitución de Polling por Webhooks Basados en Eventos
Muchos conectores antiguos utilizan polling: cada 5 minutos lanzan una consulta masiva a la API preguntando «¿Hay pedidos nuevos?» o «¿Ha cambiado algún stock?». Esto consume recursos de CPU incluso a las 3 de la madrugada cuando nadie compra.
La arquitectura correcta se basa puramente en eventos (Event-Driven):
- En WooCommerce o Shopify, un pedido pagado dispara un Webhook ligero en milisegundos con el payload en formato JSON y da por cerrada su tarea.
- En Odoo (especialmente en versiones modernas como Odoo 18 y Odoo 19), se configuran Automated Actions nativas que disparan un webhook saliente únicamente cuando el stock real disponible (
free_qtyovirtual_available) de un almacén específico sufre una variación.
2. Implementación de un Middleware con Sistema de Colas (n8n + Redis / RabbitMQ)
En lugar de apuntar los webhooks de Shopify o WooCommerce directamente a la URL de Odoo, los apuntamos a una capa intermedia (Middleware). Utilizar orquestadores como n8n autohospedado configurado en modo Queue con Redis permite absorber ráfagas masivas de tráfico sin inmutarse.
Si una campaña en televisión o con influencers genera 500 pedidos en un minuto:
- El e-commerce escupe 500 webhooks hacia el middleware.
- Redis los almacena en memoria en cuestión de microsegundos y devuelve un código
200 OKa la tienda online. - El orquestador va sacando los pedidos de la fila de uno en uno (o en bloques de 5) y los inserta en Odoo al ritmo exacto que tus workers pueden digerir sin degradar el rendimiento de los usuarios internos.
3. Batching: De 1.000 llamadas individuales a 1 sola petición
Uno de los mayores pecados de los plugins comerciales al sincronizar tarifas o inventarios es iterar producto por producto: si cambian 1.000 precios en Odoo, el conector ejecuta 1.000 llamadas HTTP independientes a la REST API de WooCommerce o GraphQL de Shopify.
Un middleware bien diseñado agrupa (batching) las modificaciones:
- Acumula los cambios de stock ocurridos durante una ventana de 60 segundos.
- Elimina duplicidades (si un mismo SKU ha cambiado 3 veces en ese minuto, se queda solo con el estado final).
- Lanza una única llamada utilizando el endpoint
/wp-json/wc/v3/products/batchen WooCommerce oinventorySetQuantitiesen GraphQL para Shopify, reduciendo la carga de red y de base de datos en un 98%.
4. Claves de idempotencia para evitar duplicados
¿Qué ocurre si la red parpadea justo cuando el pedido se estaba guardando en Odoo y el sistema reintenta el envío 10 segundos después? En una integración básica, te encuentras con dos pedidos idénticos y el doble de stock descontado.
Para blindar la operación, implementamos idempotencia. Antes de ejecutar el método create en el modelo sale.order, el flujo verifica de forma indexada un identificador único inmutable (como el order_id de origen + un hash de transacción) en un campo personalizado (x_ecommerce_order_id). Si la clave ya existe, el sistema actualiza el estado o ignora la petición duplicada, garantizando una integridad contable absoluta.
El impacto directo en tu cuenta de resultados (ROAS y Operaciones)
Tratar la integración entre tu tienda y tu ERP como un asunto «de informáticos» es un error estratégico que impacta de lleno en el margen neto de la compañía:
- Protección del ROAS en campañas de Paid Media: No sirve de nada optimizar al milímetro tus campañas en Google Ads o Meta Ads si, cuando logras concentrar la demanda en un pico de tráfico, la lentitud del checkout inducida por el ERP hunde tu tasa de conversión (CRO) del 2,5% al 0,8%.
- Ahorro directo en licencias e infraestructura: Antes de pagar miles de euros adicionales al año contratando más workers en Odoo.sh o ampliando servidores dedicados por supuestos problemas de rendimiento, auditar y desacoplar las llamadas a la API suele liberar entre un 40% y un 65% de la carga de CPU del ERP.
- Escalabilidad Multi-tienda y B2B/B2C: Una vez que tienes una capa de middleware gobernando los datos, conectar una segunda tienda en otro país, un portal B2B o un marketplace como Amazon o Mirakl no requiere instalar nuevos plugins pesados en tu web; simplemente añades un nuevo conector de salida a tu tubería de datos central.
Preguntas frecuentes sobre la sincronización de Odoo con E-commerce (FAQ)
Porque la mayoría de los plugins comerciales ejecutan llamadas síncronas en tiempo real durante la navegación del usuario o en el proceso de pago. Cada vez que el plugin consulta stock, precios por tarifa o crea un pedido en Odoo, obliga a WordPress (PHP) a esperar la respuesta del servidor de Odoo antes de terminar de cargar la página al cliente.
De forma nativa, Odoo utiliza XML-RPC y JSON-RPC sobre HTTP. Aunque JSON-RPC es ligeramente más ligero en el transporte de datos que XML-RPC, el protocolo en sí no es lo que bloquea el servidor, sino la concurrencia y la frecuencia de las llamadas. La clave no es cambiar de protocolo, sino colocar una cola asíncrona delante de la API para regular el tráfico y agrupar peticiones en lotes (batching).
La regla general de Odoo es asignar 1 worker por cada 6 usuarios concurrentes internos, más 1 worker de cron por cada núcleo disponible. Sin embargo, si tu e-commerce ataca la API de forma directa sin colas, ni siquiera 16 workers te salvarán en un pico de tráfico de 200 compras por minuto. Con una arquitectura asíncrona desacoplada, una instancia estándar de 4 a 6 workers puede procesar decenas de miles de pedidos diarios sin bloqueos.
En Inprofit no nos limitamos a instalar plugins y cruzar los dedos. Diseñamos e implementamos arquitecturas tecnológicas donde tu web, tu CRM/ERP (Odoo) y tus canales de captación se comunican mediante flujos de datos asíncronos, seguros y preparados para escalar sin fricciones.
Si sufres lentitud en el checkout, discrepancias de inventario o bloqueos en tu ERP cada vez que escalas tus campañas, solicita una auditoría técnica de tu ecosistema con nuestro equipo de ingeniería MarTech y convirtamos tu infraestructura en una ventaja competitiva real.
Marketing tecnológico en vena. Fanático de las tecnologías Martech que rompen moldes: IA generativa, blockchain, no-code, metaverso, automatización extrema… Convencido de que el futuro no se espera, se construye (y se vende muy bien).
Responsable del marketing más disruptivo y tecnológico.
