¿Qué es Event Sourcing?

Casi todos los sistemas almacenan el presente. Una fila en una tabla guarda el saldo de una cuenta, el estado de un pedido, la dirección actual de un usuario, y cada actualización sobrescribe lo que había antes. El valor es correcto, pero la historia desaparece. Puedes ver que el saldo es $40; no puedes ver que fue $100, luego $10, luego $40, ni por qué.

Event sourcing toma la decisión opuesta. En lugar de almacenar el estado actual, almacena la secuencia de cambios que lo produjo.

El modelo mental: el libro mayor, no el saldo

La analogía más clara es el libro mayor de un contador. Un banco no guarda un único número para tu saldo y lo edita en cada transacción. Registra cada depósito y cada retiro como un asiento permanente. Tu saldo es simplemente la suma de esas líneas: un valor calculado a partir de la historia, nunca almacenado como la verdad por sí mismo.

Event sourcing aplica esta disciplina al software. Los eventos son la fuente de verdad. El estado es una proyección.

En concreto, un carrito de compras no se almacena como { items: [A, B] }. Se almacena como los hechos que le ocurrieron:

1
CarritoCreado        (id: 42)
2
ArticuloAgregado     (sku: A)
3
ArticuloAgregado     (sku: B)
4
ArticuloAgregado     (sku: C)
5
ArticuloQuitado      (sku: C)

Para responder «¿qué hay en el carrito 42 ahora mismo?», reproduces esos eventos desde el principio y los pliegas en una vista actual: A y B. Los eventos nunca cambian. La vista es desechable y siempre puede reconstruirse.

Cómo se relaciona con la arquitectura orientada a eventos

Event sourcing suele confundirse con la arquitectura orientada a eventos, y ambas están relacionadas pero son distintas.

La arquitectura orientada a eventos trata sobre la comunicación entre componentes: los servicios anuncian hechos y otros servicios reaccionan sin ser llamados directamente. Los eventos son mensajes en tránsito.

Event sourcing trata sobre la persistencia dentro de un componente: los eventos son el registro duradero de todo lo que ocurrió, y son la base de datos. Los eventos se almacenan, no solo se transmiten.

Se componen con naturalidad. Un servicio con event sourcing ya tiene un flujo de hechos que describe su propia historia, así que publicar esos mismos hechos al exterior es casi gratis. Pero puedes hacer uno sin el otro: puedes ser orientado a eventos con una base de datos común, y puedes usar event sourcing sin publicar jamás un mensaje.

Cuándo usarlo

Event sourcing justifica su complejidad en un conjunto concreto de situaciones:

• La auditoría y el cumplimiento son requisitos de primer orden. Cuando «¿quién cambió qué y cuándo?» es una obligación legal, un registro de hechos solo-de-anexado no es un costo: es la funcionalidad.
• La historia en sí tiene valor. La analítica, la depuración y el aprendizaje automático suelen querer el camino completo, no solo el destino. Event sourcing lo conserva por defecto.
• Necesitas consultas temporales. «¿Cómo se veía esto el martes pasado?» se convierte en una reproducción hasta un punto en el tiempo, en lugar de una pregunta imposible.
• La lógica de negocio es genuinamente de forma de evento. Dominios como la contabilidad, el trading y la logística ya piensan en transacciones inmutables.
• Se combina con CQRS. Como las lecturas se sirven desde proyecciones y no desde el modelo de escritura, puedes construir muchas vistas de lectura especializadas a partir del mismo registro de eventos.

Cuándo no usarlo

El patrón no es un valor por defecto, y aplicarlo en todas partes es un error común y costoso.

Evítalo cuando el estado actual es todo lo que alguien preguntará jamás, cuando el dominio no tiene una historia significativa, o cuando el equipo no está listo para operar las proyecciones y la evolución de esquema que el patrón exige. La simplicidad que encaja con el problema vence a la sofisticación que no.

Ideas clave

• Event sourcing almacena un registro de hechos solo-de-anexado y trata el estado actual como una proyección derivada, no como la fuente de verdad.
• El modelo mental es un libro mayor: registras cada cambio y calculas el saldo reproduciéndolo.
• Es distinto de la arquitectura orientada a eventos —persistencia frente a comunicación— aunque ambos se componen bien.
• Recúrrelo cuando la historia, la auditoría o las consultas temporales tengan valor real; evítalo para un CRUD simple donde solo importa el presente.

La pregunta que responde event sourcing no es «¿qué es verdad ahora?», sino «¿qué ocurrió, en orden, para que fuera verdad?». Cuando esa segunda pregunta importa, almacenar la respuesta es todo el objetivo.