Cada dia, milers de botigues online perden comandes, dupliquen registres o desquadren l'estoc. No perquè WooCommerce o el seu ERP tinguin bugs, sinó perquè la seva arquitectura d'integració no està dissenyada per garantir que cada event del negoci es registri exactament una vegada i en l'ordre correcte.
Event sourcing és un patró d'arquitectura que resol exactament aquest problema. I no és teoria acadèmica: és el que fan sistemes com Stripe, Netflix o Amazon per no perdre ni una sola transacció.
Què és event sourcing
En lloc de guardar 'l'estat actual' d'una comanda (estat = completada, total = 150€), event sourcing guarda la seqüència d'events que han portat a aquest estat:
OrderCreated— Client #567 crea comanda amb 3 productesPaymentReceived— Es confirma el pagament de 150€ via StripeStockReserved— Es reserven 3 unitats a l'ERPInvoiceGenerated— Es genera factura #F-2026-0234OrderShipped— Es confirma l'enviament amb tracking XYZ
Cada event és immutable (no es pot modificar ni esborrar) i ordenat (té un timestamp i un número de seqüència). L'estat actual de la comanda es reconstrueix 'reproduint' els events.
Per què importa en ecommerce
1. Auditoria perfecta
Amb event sourcing, tens l'historial complet de cada comanda. No només 'la comanda està completada', sinó exactament quan va passar cada pas, qui ho va fer, i en quin ordre. Això és crític per a la traçabilitat fiscal que exigeix VeriFactu.
2. Cap comanda perduda
Si un event no es pot processar (l'ERP està offline, timeout, error), l'event queda a la cua. No es perd. Quan el sistema es recupera, l'event es processa automàticament. Zero pèrdua de dades.
3. Detecció natural de duplicats
Cada event té un ID únic. Si el sistema rep un event amb un ID que ja existeix al log, l'ignora. La idempotència és un subproducte natural del disseny, no un pegat afegit.
4. Reconstrucció d'estats
Si necessites saber l'estat d'una comanda en un moment concret del passat (per exemple, per a una auditoria), pots 'rebobinar' els events fins a aquell punt. Cap sistema basat en CRUD pot fer això.
Event sourcing vs sincronització per lots
| Característica | Sincronització per lots (plugins) | Event sourcing (middleware) |
|---|---|---|
| Freqüència | Cada 5-15 min | Temps real (event-driven) |
| Pèrdua de dades | Possible (webhooks fallits) | Impossible (cua persistent) |
| Duplicats | Freqüents | Previnguts per disseny |
| Auditoria | Limitada (snapshot actual) | Completa (historial d'events) |
| Recuperació d'errors | Manual | Automàtica amb retry |
| Escalabilitat | Lineal (més productes = més lent) | Horitzontal (afegir consumers) |
Exemple pràctic: una comanda amb event sourcing
Un client compra 2 unitats del producte A a la teva botiga WooCommerce. Això és el que passa amb un middleware basat en event sourcing:
- T+0ms: WooCommerce crea la comanda. El middleware intercepta l'event
OrderCreatedi el publica a la cua. - T+50ms: El consumer de l'ERP rep l'event, crea la comanda a l'ERP, i confirma el processament.
- T+80ms: El consumer d'estoc rep l'event, reserva 2 unitats del producte A a l'ERP, i actualitza l'estoc a WooCommerce.
- T+100ms: El consumer de facturació rep l'event de pagament confirmat i genera la factura automàticament.
- Tot en menys de 200ms. Amb garantia que si qualsevol pas falla, l'event es reintenta automàticament.
Probablement no tens diversos problemes
Comandes perdudes, stock inconsistent, factures que no casen. No són problemes independents. Són símptomes d'una arquitectura que no garanteix la integritat de cada event del negoci.
WooCommerce i el teu ERP creuen ser la font de veritat al mateix temps. Quan ambdues conviuen sense control, apareixen incoherències. No és un bug puntual. És un problema d'integritat transaccional.