Event sourcing o state sourcing: cuándo usar cada uno

event sourcing o state sourcing
Valora esta página

Elegir correctamente entre event sourcing o state sourcing no es solo una cuestión técnica, sino también estratégica. En este artículo, te explicamos qué significa cada patrón, cuáles son sus ventajas y sus limitaciones, y en qué escenarios resulta más conveniente aplicar cada uno.

¿Qué es event sourcing?

Event sourcing es un patrón de arquitectura que se basa en almacenar cada cambio de estado de una entidad como un evento inmutable. En lugar de guardar el estado final o actual, se guarda la secuencia completa de eventos que llevaron a ese estado. Estos eventos son registrados cronológicamente y se convierten en la fuente de verdad del sistema.

Por ejemplo, en lugar de almacenar que una cuenta bancaria tiene un saldo de 300 unidades, se almacenan todos los eventos relevantes: cuándo se creó la cuenta, cuándo se hicieron depósitos o retiros, y con qué montos. Para conocer el estado actual, el sistema reproduce toda la secuencia de eventos desde el inicio.

Ventajas del event sourcing

Una de las principales ventajas es la trazabilidad completa. Con event sourcing, es posible saber exactamente qué ocurrió, en qué orden y cuándo. Esto lo hace ideal para sectores que requieren cumplir con normativas estrictas o donde se necesita auditar el comportamiento del sistema, como en el financiero o sanitario.

Otra ventaja clave es la capacidad de «viajar en el tiempo». Dado que se tiene el historial completo de eventos, se puede reconstruir el estado de una entidad tal como estaba en cualquier punto del pasado. Esto es útil tanto para pruebas como para análisis forenses.

Además, event sourcing habilita la integración con otros sistemas a través de eventos publicados. Los mismos eventos que modifican el estado interno pueden ser consumidos por otros servicios para sincronización o reacciones automatizadas.

Desventajas del event sourcing

Sin embargo, este enfoque también tiene costos. El principal es su complejidad técnica y conceptual. Implementar event sourcing requiere definir eventos cuidadosamente, asegurar su inmutabilidad, versionarlos cuando cambian y crear mecanismos para reconstruir estados desde largas secuencias de eventos.

Otra desventaja es el posible impacto en el rendimiento. Reconstruir el estado de una entidad con cientos o miles de eventos puede ser costoso si no se implementan mecanismos adicionales, como los snapshots (puntos de control del estado actual).

Finalmente, event sourcing requiere una curva de aprendizaje significativa para los equipos de desarrollo y operación. No todos los casos de uso justifican esta inversión.

¿Qué es state sourcing?

State sourcing, por otro lado, es el enfoque tradicional en el que el sistema guarda directamente el estado actual de una entidad. Cada vez que ocurre un cambio, el nuevo estado sobrescribe al anterior. Es el modelo usado en aplicaciones CRUD (crear, leer, actualizar, eliminar).

En este enfoque, una aplicación almacena la versión más reciente del estado, como por ejemplo el saldo actual de una cuenta bancaria, sin guardar el detalle de cómo se llegó a ese valor. Si se requiere historial, debe construirse un mecanismo adicional de auditoría o logging, lo que implica más esfuerzo y mayor mantenimiento.

Ventajas del state sourcing

La mayor ventaja de este patrón es su simplicidad. Es fácil de implementar, ampliamente entendido por los equipos de desarrollo y compatible con la mayoría de las bases de datos relacionales y no relacionales existentes.

También ofrece eficiencia inmediata en las lecturas. Como el estado actual está disponible directamente, las operaciones de consulta suelen ser más rápidas y sencillas que en event sourcing.

Asimismo, la mayoría de los frameworks, ORMs y herramientas de análisis están diseñados para trabajar con modelos de datos basados en state sourcing, lo cual reduce fricciones técnicas.

Desventajas del state sourcing

La principal desventaja es la pérdida de trazabilidad. Una vez actualizado el estado, se pierde la información sobre cómo y por qué se llegó a ese punto, salvo que se haya implementado una solución específica para conservar ese historial.

Esto también representa un reto para industrias en las que la transparencia es esencial. El state sourcing por sí solo no permite reconstruir fácilmente el contexto de decisiones o transacciones.

Otro aspecto limitante es su menor capacidad de adaptación en arquitecturas distribuidas orientadas a eventos, en las que es necesario propagar los cambios de manera asincrónica a través de múltiples servicios.

¿Cuándo elegir event sourcing?

Event sourcing es recomendable cuando se necesita un historial completo de cambios, una fuerte capacidad de auditoría, o cuando los eventos pueden ser utilizados como una forma de integración entre servicios.

Casos típicos incluyen sistemas financieros, plataformas de comercio electrónico con lógica de pedidos compleja, gestión de procesos de negocio con múltiples etapas, y cualquier contexto regulado que exija rendición de cuentas detallada.

También es muy útil cuando la lógica de negocio evoluciona con el tiempo, ya que permite analizar decisiones pasadas bajo nuevas reglas o aplicar correcciones retroactivas.

¿Cuándo elegir state sourcing?

State sourcing es la mejor opción cuando la simplicidad, la velocidad de desarrollo y la eficiencia de lectura son más importantes que la trazabilidad. Es ideal para aplicaciones administrativas, herramientas internas, paneles de control, o sistemas en los que los datos no cambian con frecuencia o no requieren historial detallado.

Además, es el enfoque más común para startups en etapas tempranas, en las que la prioridad es lanzar rápidamente sin agregar complejidad innecesaria.

En general, si el sistema puede vivir sin la capacidad de reconstruir el pasado y si los cambios de estado no necesitan propagarse o procesarse como eventos independientes, el state sourcing suele ser suficiente.

Consideraciones prácticas

Antes de elegir entre event sourcing o state sourcing, las organizaciones deben considerar los siguientes factores:

  • ¿Necesitamos tener un historial detallado de cada cambio?
  • ¿Qué impacto tendría perder la trazabilidad sobre el estado?
  • ¿El sistema deberá integrarse con otros servicios mediante eventos?
  • ¿Nuestros equipos tienen la experiencia técnica necesaria para manejar arquitecturas basadas en eventos?
  • ¿Qué implicaciones tiene cada modelo en términos de mantenimiento, pruebas y evolución?

En muchos casos, una combinación híbrida también es posible. Algunas entidades pueden beneficiarse del event sourcing, mientras que otras pueden permanecer en un modelo de state sourcing simple. El reto está en identificar correctamente qué parte del dominio requiere qué nivel de sofisticación.

Seleccionar entre event sourcing o state sourcing no es una decisión menor. Afecta no solo la arquitectura técnica de una solución, sino también la capacidad de la organización para escalar, adaptarse y responder ante auditorías o incidentes.

Facebook
Twitter
LinkedIn
Email