Event Sourcing

Resumen

Event Sourcing es un patrón de persistencia donde cada cambio en el estado de una entidad se registra como un evento inmutable en un log. El estado actual no se guarda directamente: se obtiene re-ejecutando —o proyectando— todos los eventos desde el inicio. Si una cuenta bancaria empieza en $0 y recibe eventos Deposit($100), Deposit($50), Withdraw($30), el saldo actual es $120 y se calcula aplicando esos eventos en orden.

Importa porque el log de eventos es un historial completo y auditable de todo lo que pasó en el sistema. Podés reconstruir el estado en cualquier punto del tiempo, depurar bugs reproduciendo la secuencia exacta de eventos, y generar múltiples proyecciones —modelos de lectura— para distintos casos de uso.

Event Sourcing se combina naturalmente con CQRS: el modelo de escritura guarda eventos, y proyecciones asíncronas construyen los modelos de lectura. También es la base para patrones como Saga, donde los eventos coordinan flujos entre servicios.

Alcance y supuestos

Este paquete cubre el concepto a nivel arquitectónico: qué es, qué problema resuelve, cómo se relaciona con otros patrones del ecosistema, y en qué contexto tiene sentido aplicarlo. No cubre detalles de implementación específicos de cada tecnología ni configuraciones de proveedores cloud concretos. Asume que el lector entiende los fundamentos de sistemas distribuidos y arquitectura de software.

Modelo mental

El libro contable de un negocio. No borrás la entrada anterior y escribís el nuevo saldo —eso sería un banco que solo te dice cuánta plata tenés sin mostrarte los movimientos—. Cada transacción se registra en una línea nueva: fecha, concepto, monto. Para saber el saldo actual, sumás todas las líneas. Para saber cuánto había en junio, sumás solo hasta esa fecha. Event Sourcing es ese libro contable.

Uso práctico

• ✅ Auditoría y compliance: cada cambio está registrado y es inmutable.
• ✅ Depuración: reconstruir el estado en el momento exacto de un bug.
• ✅ Proyecciones múltiples: un mismo log de eventos alimenta modelos de lectura distintos.
• ❌ Complejidad: no es para CRUD simple. El costo de implementar event sourcing se paga cuando el dominio lo justifica.
• ❌ Tamaño del log: los eventos se acumulan. Snapshots periódicos mitigan el problema de re-ejecutar eventos desde el inicio.

Ejemplo trabajado: reconstruir estado desde eventos

Una cuenta bancaria tiene 3 años de eventos: AccountOpened, Deposit, Withdraw, FeeApplied. Para calcular el saldo actual, el sistema re-ejecuta todos los eventos. Para un cliente que quiere ver su saldo de hace 6 meses, re-ejecuta solo hasta esa fecha. Si se descubre un bug en el cálculo de fees, se corrige el código y se re-ejecutan todos los eventos —el saldo se recalcula correctamente para toda la historia, sin migraciones de base de datos.

Evidencia

• Wikipedia, Event sourcing define el patrón, explica la diferencia con persistencia tradicional y describe la relación con CQRS y las proyecciones.