Event sourcing o modelo tradicional: cómo decidir qué guardar como fuente de verdad

Elegir cómo persistir los datos de una aplicación no es solo una decisión de almacenamiento. Define qué se puede reconstruir, cómo se explican los cambios y cuánto trabajo exige mantener el sistema. Event sourcing guarda una secuencia de eventos como fuente de verdad; un modelo tradicional suele guardar el estado vigente y, si hace falta, un historial complementario.

Ninguna opción es superior en todos los casos. La pregunta útil es cuándo el historial completo y la reconstrucción aportan suficiente valor para justificar una arquitectura más exigente. Esta guía propone criterios prácticos para decidir, identificar alternativas más sencillas y empezar con un alcance controlado.

Qué significa event sourcing y qué cambia frente al modelo tradicional

En event sourcing, la aplicación registra hechos de negocio que ya ocurrieron, como PedidoCreado, PagoConfirmado o DirecciónActualizada. El estado actual se obtiene aplicando esos eventos en orden. En lugar de sobrescribir una fila con el último valor, se conserva una secuencia que describe cómo evolucionó la entidad.

En un modelo tradicional, la base de datos contiene normalmente la versión vigente: por ejemplo, el estado actual de un pedido y su importe. Una actualización reemplaza valores anteriores. Si se necesita conocer quién cambió un dato, cuándo o cuál era su valor previo, puede añadirse un registro de auditoría o un historial específico.

La diferencia decisiva no es que un enfoque tenga historial y el otro no. Es qué registro es la autoridad. En event sourcing, los eventos son la fuente de verdad y las vistas actuales se derivan de ellos. En un modelo tradicional, el estado persistido suele ser la autoridad; el historial, cuando existe, cumple una función adicional.

Empieza por el problema, no por la arquitectura

Antes de elegir, concreta qué pregunta de negocio no puedes responder hoy. “Queremos más trazabilidad” es demasiado general; “necesitamos reconstruir qué decisiones produjeron el saldo de una cuenta en una fecha determinada” expresa una necesidad comprobable. Esa precisión permite comparar soluciones sin adoptar una arquitectura por su atractivo técnico.

• Historial: hace falta consultar cambios anteriores, pero no necesariamente reconstruir todo el estado. Un registro de auditoría puede bastar.
• Reconstrucción: se necesita recalcular el estado a partir de hechos conservados, por ejemplo, para corregir una regla de negocio o analizar una situación histórica.
• Trazabilidad: importa explicar qué ocurrió y en qué orden. Puede resolverse con eventos de negocio o con un historial diseñado para ese propósito.
• Consultas actuales: la mayoría de las pantallas solo necesita leer el estado vigente. Un modelo tradicional puede ofrecer un camino más directo.

También conviene comprobar si el requisito es permanente y central para el producto, o si aparece en un único proceso. Event sourcing tiene más sentido cuando la secuencia de cambios forma parte esencial del dominio, no solo cuando alguien quiere “guardar todo”.

Criterios prácticos para decidir

Evalúa cada criterio con ejemplos reales del dominio. No hace falta que todos apunten a event sourcing, pero sí entender qué requisito está impulsando la elección.

• Los cambios tienen significado propio: “reserva confirmada” o “reembolso aprobado” son hechos relevantes, no simples modificaciones de campos. Esto favorece modelar eventos explícitos.
• La reconstrucción es necesaria: el negocio necesita volver a obtener estados anteriores o recalcularlos con reglas nuevas. Si solo se requiere mostrar los últimos cambios, un historial puede ser suficiente.
• El orden importa: la secuencia de acciones determina el resultado, y el equipo necesita conservarla de manera fiable.
• Existen varias vistas del mismo proceso: distintos equipos o funciones necesitan consultar los mismos hechos de formas diferentes. Las proyecciones pueden servir esas lecturas, aunque añaden trabajo.
• El dominio tiene correcciones y excepciones: se deben representar como nuevos hechos —por ejemplo, una corrección o reversión— sin borrar silenciosamente lo sucedido. Hay que definir con cuidado qué significa cada evento.

Si la necesidad se limita a actualizar registros y consultar su versión vigente, el modelo tradicional probablemente sea más sencillo. Si el historial debe ser completo, comprensible y utilizable para derivar estados, event sourcing merece una evaluación más profunda.

Costes, riesgos y señales para descartarlo

Guardar eventos no elimina la complejidad: la desplaza. Las lecturas suelen depender de proyecciones, es decir, vistas derivadas que se actualizan a partir de los eventos. Si estas se procesan de forma asíncrona, puede haber consistencia eventual: durante un intervalo, una lectura refleja un estado anterior. El producto debe tolerarlo o definir cómo presentar y gestionar ese retraso.

Además, los eventos persistidos no se editan como si fueran filas corrientes. Al cambiar el dominio, hay que decidir cómo interpretar eventos antiguos, cómo evolucionan sus formatos y cómo se reconstruyen las proyecciones. También se necesitan procedimientos para detectar fallos de procesamiento, repetir eventos cuando sea seguro y mantener operaciones y soporte. Una secuencia incompleta o mal definida puede perjudicar precisamente la reconstrucción que se buscaba.

Conviene descartar o aplazar event sourcing si el equipo no puede explicar qué eventos representan hechos de negocio, si las consultas requeridas son simples o si el sistema no necesita reconstrucción. También es una señal de alerta que el principal argumento sea “tener auditoría”, sin requisitos sobre consultas históricas, conservación o uso de ese registro. En esos casos, una tabla de historial bien diseñada puede cubrir el objetivo con menos piezas.

Ejemplo hipotético: pedidos con cambios y correcciones

Imaginemos una aplicación que gestiona pedidos. El equipo necesita mostrar estado, importe y dirección actuales. Un modelo tradicional con datos del pedido y un historial de cambios puede ser suficiente si el objetivo es consultar la versión vigente y explicar modificaciones recientes.

La decisión cambia si el negocio necesita reconstruir cómo se llegó al importe, distinguir confirmaciones de correcciones y volver a calcular situaciones históricas según reglas nuevas. Event sourcing podría registrar hechos como pedido creado, pago confirmado y corrección de importe. La vista del pedido se derivaría de esa secuencia. Pero habría que decidir cómo representar una corrección, cómo manejar eventos antiguos y qué lecturas pueden mostrar datos temporalmente desactualizados.

El ejemplo no implica que todo proceso de pedidos necesite event sourcing. La elección depende de requisitos verificables: qué reconstrucción se exige, quién consulta el historial y qué nivel de complejidad puede operar el equipo.

Preguntas de comprobación antes de adoptar event sourcing

1. ¿Qué pregunta concreta no puede responderse con el estado actual y un historial sencillo?
2. ¿Qué entidades o procesos necesitan reconstrucción, y con qué propósito de negocio?
3. ¿Los eventos describen hechos con significado estable o solo copian cambios técnicos de campos?
4. ¿Qué vistas hay que mantener, quién las consume y cuánto retraso pueden tolerar?
5. ¿Cómo se tratarán correcciones, eventos duplicados, cambios de formato y reprocesamientos?
6. ¿Quién será responsable de supervisar las proyecciones y resolver fallos de procesamiento?
7. ¿Hay una alternativa más simple que satisfaga los requisitos actuales sin cerrar opciones futuras?

Empieza acotado y revisa la decisión

Si los requisitos justifican event sourcing, delimita la adopción a un proceso cuyo historial tenga valor claro. Define primero el vocabulario de eventos con responsables del dominio y acuerda qué garantiza cada evento: qué ocurrió, qué datos hacen falta para interpretarlo y qué no debe cambiarse después. Diseña también las consultas principales y la recuperación de proyecciones antes de ampliar el alcance.

Registra las decisiones y revisa la arquitectura cuando cambien las necesidades. Si el producto deja de requerir reconstrucción, o el coste de mantener proyecciones supera su utilidad, simplificar puede ser razonable. Si aparecen nuevos requisitos de trazabilidad y análisis, un historial convencional puede dejar de bastar. La mejor elección es la que responde a necesidades reales y el equipo puede operar con fiabilidad, no la que acumula más mecanismos por anticipado.