Event sourcing: qué es y en qué se diferencia del CDC

El event sourcing es un patrón en el que el sistema no almacena el estado actual de las cosas, sino la secuencia completa de eventos que lo han producido. El estado se obtiene reproduciendo esos eventos en orden.

La diferencia con el enfoque habitual se ve con un ejemplo. Una aplicación clásica guarda que la cuenta tiene un saldo de 400 y lo sobrescribe cada vez que cambia: el valor anterior desaparece. Con event sourcing se guardan los hechos —«ingreso de 500», «cargo de 100»— y el saldo de 400 es el resultado de sumarlos. Los hechos no se modifican nunca; corregir algo significa añadir un evento nuevo que compensa al anterior, igual que un asiento contable.

Qué resuelve

El histórico deja de ser un añadido. En un sistema que sobrescribe, saber cómo se llegó al valor actual exige haber montado tablas de auditoría por separado y confiar en que nadie se saltó ninguna. Aquí el histórico es el propio almacenamiento: no se puede perder sin perder también el estado.

Se puede preguntar por el pasado. Como el estado se deriva, se puede derivar hasta una fecha concreta y responder a qué saldo tenía esa cuenta el último día del trimestre, con la certeza de que la respuesta es reconstruible y no una foto que alguien guardó.

Admite vistas nuevas sobre datos viejos. Si más adelante hace falta una proyección distinta —otro modelo de lectura, otro agregado— se construye reproduciendo los eventos desde el principio. El dato para alimentarla ya existe, aunque cuando se emitieron los eventos nadie hubiera pensado en esa vista.

Encaja de forma natural con la integración por eventos. Los eventos ya están ahí, así que publicarlos hacia otros sistemas no exige un mecanismo aparte.

En qué se diferencia del CDC

Es la confusión más frecuente, porque ambos producen un flujo de cambios. La diferencia está en el origen y, sobre todo, en la intención.

El CDC observa una base de datos que sobrescribe su estado y deduce los cambios leyendo su registro de transacciones. El flujo resultante es técnico: describe que una fila pasó de un valor a otro. La aplicación no sabe que está siendo observada, y por eso el CDC se puede añadir a un sistema existente sin tocarlo.

En event sourcing el evento es la forma primaria en que la aplicación guarda las cosas, y describe una intención de negocio: «pedido cancelado por el cliente», no «el campo estado pasó de 2 a 5». Esa diferencia de vocabulario es lo que hace reconstruibles las proyecciones, y también lo que impide adoptarlo sin rediseñar la aplicación.

En resumen: el CDC es una técnica de integración que se aplica desde fuera; el event sourcing es una decisión de diseño que se toma desde dentro.

Lo que cuesta

Los eventos son para siempre. Una vez escrito, un evento no se cambia. Eso obliga a que el código sepa leer formatos antiguos indefinidamente, o a versionar y migrar el registro con mucho cuidado. Un esquema de eventos mal pensado al principio sale caro durante años.

La lectura se complica. Responder a una consulta corriente puede exigir reproducir muchos eventos, así que en la práctica se mantienen proyecciones —vistas materializadas del estado— que hay que reconstruir cuando cambian. Con ello llega la consistencia eventual: la proyección puede ir un poco por detrás de los eventos.

La reproducción tiene que ser repetible. Procesar dos veces el mismo evento no puede producir un resultado distinto, lo que convierte la idempotencia en un requisito y no en una buena práctica. Es el mismo problema que se plantea al buscar entrega exactamente una vez en un sistema de mensajería.

Borrar es un problema real. Un registro inmutable convive mal con la obligación de eliminar datos personales, y la solución habitual —guardar el dato sensible fuera y destruir la clave— hay que preverla desde el diseño.

Cuándo compensa

Cuando el histórico de cómo se llegó al estado actual es en sí mismo parte del negocio: finanzas, seguros, logística, cualquier dominio donde ya se razona en términos de asientos, movimientos o trazabilidad. En esos casos el patrón describe lo que ya se hacía a mano.

No compensa como decisión por defecto ni para un dominio sencillo de altas, bajas y modificaciones: ahí añade complejidad permanente a cambio de una capacidad que nadie va a usar. Y si lo que se necesita es llevar los cambios de una base de datos existente a un almacén analítico, la herramienta correcta es el CDC, no rediseñar la aplicación.

En el directorio de herramientas de integración de datos de Dataprix hay análisis de las plataformas con las que se transportan y procesan estos flujos, y el encaje de los eventos dentro de una plataforma de datos está tratado en la guía de arquitectura de datos.