El event sourcing es un patrón de persistencia radical: en vez de guardar el estado actual de las entidades (la última versión de cada fila), se guarda la secuencia inmutable y ordenada de eventos que las han modificado. El estado actual se calcula reproduciendo esos eventos desde el principio (o desde un snapshot) para cada agregado. La fuente de verdad pasa a ser el log de eventos, no las tablas de estado.
Las ventajas son notables: auditoría completa por construcción (cada cambio está registrado, no se borra nada), capacidad de "time travel" (reconstruir el estado en cualquier momento del pasado), nuevas vistas/proyecciones añadibles a posteriori (reproduces los eventos contra un nuevo modelo de lectura), y desacoplamiento perfecto entre commands y queries (combina especialmente bien con CQRS). En sectores con fuerte requisito regulatorio (banca, salud, seguros) el log de eventos puede sustituir parte del compliance.
Las desventajas son igual de reales: complejidad importante (versionado de eventos al evolucionar el schema, migraciones complicadas, queries ad-hoc difíciles), eventual consistency entre los modelos de escritura y de lectura, curva de aprendizaje del equipo, y la trampa de los "eventos CRUD" (PedidoActualizado en vez de PrecioReducido, EstadoCambiado) que rompen el valor del patrón. Si los eventos no son hechos de negocio significativos, event sourcing se convierte en una BD más complicada sin ventajas reales.
En 10Code usamos event sourcing con moderación, solo cuando el dominio lo pide: trazabilidad financiera, auditoría regulatoria, plataformas de pagos. Para la mayoría de productos, una base relacional bien modelada con tablas de histórico cubre las necesidades con muchísima menos complejidad. La regla: nunca elegir event sourcing por novedad técnica; siempre por requisito real.
En 10Code llevamos más de una década aplicando estas tecnologías a productos reales. Si quieres comentarnos tu caso, escríbenos y te respondemos personalmente.
Hablar con un ingeniero