Patrones de persistencia: durable state vs event sourcing

La persistencia de datos es una pieza clave en la arquitectura de cualquier sistema y determinar cómo guardar la información impacta en el diseño del modelo. Te mostraremos dos patrones principales: durable state y event source. Exploramos además ejemplos reales con flujos de actividades y consejos ante retos comunes en arquitecturas modernas.

¿Por qué la persistencia es fundamental en el diseño de sistemas?

Elegir bien la forma en la que persistes los datos afecta tanto la flexibilidad como el control histórico de la información. Decidir entre almacenar únicamente el estado actual del modelo o cada evento que ocurre es esencial en función de los requerimientos y regulaciones.

¿Qué es el patrón durable state y para qué casos es adecuado?

• Durable state almacena el estado actual del modelo de dominio.
• Cuando una actualización ocurre, el estado anterior suele sobrescribirse.
• Es ideal para casos CRUD: create, retrieve, update and delete.
• Limita la posibilidad de responder preguntas históricas, como saber el valor anterior en una fecha específica.

¿Cómo funciona el event sourcing y qué ventajas ofrece?

• Event sourcing guarda cada cambio como un evento en una tabla especializada.
• Permite reconstruir el estado aplicando todos los eventos secuencialmente.
• Facilita auditorías, cumplimiento y la trazabilidad, ya que puedes recuperar el estado exacto en un momento pasado.
• Es común en soluciones donde la historia de cambios es vital, pero puede impactar en la velocidad de reconstrucción si los cambios son muy frecuentes.

¿Qué diferencia hay entre event sourcing y arquitecturas orientadas a eventos?

Aunque el event sourcing es popular en arquitecturas orientadas a eventos, no son lo mismo.

• Un event broker gestiona eventos entre microservicios, pero no necesariamente almacena el detalle de los eventos de negocio.
• Servicios pueden emitir o consumir notificaciones sin persistir los eventos como historial.

¿Cómo modelar flujos de actividades y estados en sistemas complejos?

Analizando problemáticas como la del Banco Interamericano de Desarrollo:

• Tablas de documentos y estados muestran dependencia y flujo entre tipos de documentos.
• Se puede rastrear qué actor realizó una modificación, con qué herramienta y sobre qué documento.
• Es clave modelar el flujo usando máquinas de estados o diagramas de actividades.

¿Por qué elegir diagramas de actividades sobre otros modelos?

• Diagramas de actividades UML ordenan flujos entre actores y objetos a lo largo del tiempo, usando lanes para cada rol.
• Permiten visualizar acciones, responsables y estados de documentos de forma clara.
• Asocian actividades con momentos específicos, ayudando a inferir necesidades de transaccionalidad.
• Aunque no son directamente diagramas de proceso, se pueden extrapolar a BPMN para mayor detalle.

¿Qué patrones y retos aparecen en arquitecturas orientadas a eventos y microservicios?

• Se aplican patrones como CQRS, event sourcing, saga (para manejar transacciones distribuidas) y coreografía (para organizar flujos complejos).
• Es necesario prevenir el event hell, un antipatrón donde la emisión descontrolada de eventos genera efectos impredecibles o suscripciones accidentales de actores no previstos.

Comenta las experiencias o dudas que surgen al implementar estos enfoques en tus propios proyectos. ¿Te has encontrado con event hell o has logrado aprovechar las ventajas del event sourcing?