Cada día, miles de tiendas online pierden pedidos, duplican registros o descuadran el stock. No porque WooCommerce o su ERP tengan bugs, sino porque su arquitectura de integración no está diseñada para garantizar que cada evento del negocio se registre exactamente una vez y en el orden correcto.
Event sourcing es un patrón de arquitectura que resuelve exactamente este problema. Y no es teoría académica: es lo que hacen sistemas como Stripe, Netflix o Amazon para no perder ni una sola transacción.
Qué es event sourcing
En lugar de guardar 'el estado actual' de un pedido (estado = completado, total = 150€), event sourcing guarda la secuencia de eventos que han llevado a ese estado:
OrderCreated— Cliente #567 crea pedido con 3 productosPaymentReceived— Se confirma el pago de 150€ vía StripeStockReserved— Se reservan 3 unidades en el ERPInvoiceGenerated— Se genera factura #F-2026-0234OrderShipped— Se confirma el envío con tracking XYZ
Cada evento es inmutable (no se puede modificar ni borrar) y ordenado (tiene un timestamp y un número de secuencia). El estado actual del pedido se reconstruye 'reproduciendo' los eventos.
Por qué importa en ecommerce
1. Auditoría perfecta
Con event sourcing, tienes el historial completo de cada pedido. No solo 'el pedido está completado', sino exactamente cuándo pasó cada paso, quién lo hizo, y en qué orden. Esto es crítico para la trazabilidad fiscal que exige VeriFactu.
2. Ningún pedido perdido
Si un evento no se puede procesar (el ERP está offline, timeout, error), el evento queda en la cola. No se pierde. Cuando el sistema se recupera, el evento se procesa automáticamente. Zero pérdida de datos.
3. Detección natural de duplicados
Cada evento tiene un ID único. Si el sistema recibe un evento con un ID que ya existe en el log, lo ignora. La idempotencia es un subproducto natural del diseño, no un parche añadido.
4. Reconstrucción de estados
Si necesitas saber el estado de un pedido en un momento concreto del pasado (por ejemplo, para una auditoría), puedes 'rebobinar' los eventos hasta ese punto. Ningún sistema basado en CRUD puede hacer esto.
Event sourcing vs sincronización por lotes
| Característica | Sincronización por lotes (plugins) | Event sourcing (middleware) |
|---|---|---|
| Frecuencia | Cada 5-15 min | Tiempo real (event-driven) |
| Pérdida de datos | Posible (webhooks fallidos) | Imposible (cola persistente) |
| Duplicados | Frecuentes | Prevenidos por diseño |
| Auditoría | Limitada (snapshot actual) | Completa (historial de eventos) |
| Recuperación de errores | Manual | Automática con retry |
| Escalabilidad | Lineal (más productos = más lento) | Horizontal (añadir consumers) |
Ejemplo práctico: un pedido con event sourcing
Un cliente compra 2 unidades del producto A en tu tienda WooCommerce. Esto es lo que pasa con un middleware basado en event sourcing:
- T+0ms: WooCommerce crea el pedido. El middleware intercepta el evento
OrderCreatedy lo publica en la cola. - T+50ms: El consumer del ERP recibe el evento, crea el pedido en el ERP, y confirma el procesamiento.
- T+80ms: El consumer de stock recibe el evento, reserva 2 unidades del producto A en el ERP, y actualiza el stock en WooCommerce.
- T+100ms: El consumer de facturación recibe el evento de pago confirmado y genera la factura automáticamente.
- Todo en menos de 200ms. Con garantía de que si cualquier paso falla, el evento se reintenta automáticamente.
Probablemente no tienes varios problemas
Pedidos perdidos, stock inconsistente, facturas que no casan. No son problemas independientes. Son síntomas de una arquitectura que no garantiza la integridad de cada evento del negocio.
WooCommerce y tu ERP creen ser la fuente de verdad al mismo tiempo. Cuando ambos conviven sin control, aparecen incoherencias. No es un bug puntual. Es un problema de integridad transaccional.