La transición de los datos relacionales a los eventos

Guía para pasar de datos relacionales a eventos

• En la iglesia del event sourcing, los datos del negocio se preservan como eventos sin perderse.
• Los eventos representan hechos que ocurrieron y se guardan después de cada operación.
• Un stream de eventos es la lista de todos los eventos registrados; es inmutable y los errores del pasado pueden corregirse agregando nuevos eventos.

1. Encontrar columnas de estado

• Los valores de las columnas de estado pueden reflejar las etapas del ciclo de vida de los datos.
• Por ejemplo, un pedido puede iniciarse, enviarse y pagarse.
• Estos estados pueden convertirse en eventos como Order Initiated, Order Shipped y Order Paid.

2. Revisar columnas de fecha

• Las columnas de fecha pueden brindar información sobre eventos importantes del proceso.
• ShipmentDate, DeliveryDate, OrderPlacementDate, etc., revelan la terminología del negocio y pueden ayudar a introducir nuevos eventos.

3. Analizar la selectividad de las columnas

• Las columnas nullable pueden proporcionarse más adelante o ser opcionales.
• Las columnas obligatorias deben proporcionarse en el primer evento Order Initiated.

4. Buscar las tablas con más relaciones de uno a muchos

• En event sourcing, se busca un procesamiento eficiente agrupando los datos alrededor de los procesos de negocio.
• Las tablas con muchas relaciones de uno a muchos pueden ser candidatas a tipos de stream.

5. Introducir eventos explícitos

• Al migrar datos relacionales a eventos, los eventos recién descubiertos no deben reutilizarse durante la importación; se debe proporcionar explícitamente un evento Order Imported.

6. Experimentar y validar

• Hay que probar prototipos en un entorno seguro, comparar los resultados con lo esperado y repetir sin apresurarse.

Opinión de GN⁺

• Lo más importante de este texto es la relevancia de un nuevo enfoque que preserve los datos del negocio durante la transición de una base de datos relacional hacia event sourcing.
• Este artículo resulta interesante porque propone una forma de salir del manejo tradicional de datos y entender mejor, además de aprovechar, el ciclo de vida de los datos.
• Event sourcing puede ayudar no solo desde una perspectiva técnica, sino también a construir una comprensión compartida entre los equipos de negocio y tecnología.

[GN⁺]

Opiniones de Hacker News

• Recomendación de usar PostgreSQL y herramientas de reporting FOSS

  • Si la aplicación ya usa PostgreSQL, se recomienda guardar los datos de eventos en PostgreSQL y usar herramientas de reporting FOSS (como Apache Superset, Metabase, etc.).
  • Se usa PostgreSQL hasta que los datos llegan a unos 2 TB, y después se decide si realmente se necesitan 2 TB de datos en línea o si basta con resúmenes diarios/por hora.
  • En el caso de un cliente, procesan más de 10 TB de datos y 1500 eventos por segundo; los datos detallados se mantienen en línea durante 2 días y el resto se resume y se mueve a S3 para poder consultarlo mediante Athena SQL.
  • Usan AWS RDS Multi-AZ para soportar failover automático, y un solo ingeniero mantiene todo con menos de 5 horas al mes.
  • PostgreSQL ofrece un sistema único para guardar los datos en un solo lugar, aprenderlo, administrarlo y escalarlo.
  • Incluso personal no técnico puede crear gráficos fácilmente en sistemas como Metabase o Preset.
  • PostgreSQL mejora cada año y, si hace falta, se puede escalar más con sistemas compatibles con PostgreSQL (Aurora, TimescaleDB, CitusDB, etc.).

• Cuándo conviene usar arquitectura orientada a eventos

  • Cuando un cliente realiza una acción específica y espera una respuesta, no se trata de algo orientado a eventos sino de un patrón de solicitud/respuesta.
  • Lo orientado a eventos se refiere a casos que ocurren de forma inesperada. Por ejemplo, cuando haces push de código a GitHub y eso dispara un build.

• Experiencia escéptica compartida sobre event sourcing

  • Un equipo consideró usar event sourcing, pero al no ver beneficios claros y por el riesgo de probar algo nuevo, al final decidió no usarlo.
  • No se arrepienten de haber perdido esa oportunidad de aprendizaje, y valoran positivamente no haberse metido en un problema complejo cuando no lo necesitaban.

• Utilidad del modelado de eventos de dominio

  • El modelado de eventos de dominio es útil para comunicarse con los expertos del dominio que intentan resolver el problema.
  • Al implementar un sistema que debe ofrecer trazabilidad de auditoría para máquinas de estado a lo largo del tiempo, es mejor usar herramientas como Temporal.io/durable functions.
  • Estas herramientas usan event sourcing internamente y obligan a escribir código considerando deduplicación e idempotencia.

• Preguntas sobre la implementación de event sourcing

  • Falta una explicación de cómo reconstruir de forma eficiente el estado actual a partir del stream de eventos y de cómo modelar ese stream de eventos en la base de datos.

• Bottom-up vs. top-down, personalizado vs. genérico

  • El enfoque top-down empieza en el dominio del negocio y mapea la implementación a la tecnología, herramientas y vendors disponibles.
  • El enfoque bottom-up empieza en la tecnología, herramientas y vendors disponibles y arma una solución funcional a partir de eso.
  • El enfoque personalizado incluye DDD, CQRS/ES, Sagas, TBUI, GraphQL, tipos de datos algebraicos, etc.
  • El enfoque genérico incluye RDBMS, CRUD, REST, transacciones ACID, CDC, UI administrativa genérica, no-code/low-code, tipos limitados/genéricos, etc.

• Apoyo y crítica a la arquitectura basada en eventos

  • Hay apoyo a la arquitectura basada en eventos, pero el artículo no logra transmitir su argumento con claridad.
  • Si se pone el foco en la diferencia entre relaciones de datos y comportamiento del negocio, resulta más claro por qué conviene alejarse del almacenamiento relacional operacional.

• Event sourcing y la necesidad de relaciones

  • A pesar de muchas de las ventajas de event sourcing, las relaciones siguen siendo necesarias.
  • Si todas las relaciones quedan implícitas en el código de la capa de aplicación, eso no es aceptable.
  • Hace falta una forma de consultar esas relaciones o de mantener actualizadas las vistas relacionales.

• Apoyo a los datos relacionales

  • Se decidió evitar la complejidad y mantenerse fiel a los datos relacionales tradicionales.

• Nueva percepción sobre el diseño orientado a eventos

  • Hace poco conocieron el diseño orientado a eventos y, mientras pensaban en la estructura de datos óptima en un mundo dominado por IA, llegaron a una conclusión parecida.
  • Creen que el diseño orientado a eventos puede valer la pena si ayuda a gestionar la complejidad y a usar realmente los datos.
  • Esperan que en los próximos años el diseño orientado a eventos se vuelva común, a medida que la IA pueda consultar con conocimiento sobre todos los eventos de negocio.