Pasar de datos relacionales a eventos

Artículo original ↗ Discusión en Hacker News ↗

Los defensores del event sourcing argumentan que almacenar cada cambio como un flujo inmutable de eventos puede preservar la historia del negocio, habilitar analítica potente y desacoplar servicios, pero muchos ingenieros en este hilo lo ven como un patrón de nicho y sobreutilizado que a menudo añade complejidad sin un beneficio claro. Los comentaristas subrayan que las bases de datos relacionales ya soportan capacidades temporales y de auditoría, y que la mayoría de los sistemas “orientados a eventos” exitosos en la práctica siguen dependiendo de almacenes SQL convencionales o de proyecciones para las consultas y la consistencia. El consenso emergente es que el event sourcing es valioso para dominios específicos como finanzas, analítica o flujos de trabajo complejos, pero es una mala sustitución por defecto de los modelos relacionales basados en CRUD.

Sentimiento general sobre el artículo

  • Muchos lectores encontraron el artículo poco claro, excesivamente seguro de sí mismo y molesto en lo estilístico.
  • Crítica principal: sugiere que el event sourcing debería “reemplazar” los enfoques CRUD/relacionales sin explicar rigurosamente los compromisos, pros/contras o pasos concretos de migración.
  • A algunos les gustó la dirección general (pensar en eventos/comportamientos), pero sintieron que el texto era una introducción superficial o confusa.

Event sourcing vs bases de datos relacionales/temporales

  • Varios comentaristas subrayan que el event sourcing y el modelo relacional son ortogonales: se puede hacer event sourcing sobre bases de datos SQL.
  • Las bases de datos relacionales ya soportan patrones temporales (p. ej., tablas de auditoría, journals, características de SQL:2011).
  • Se señala que Datalog y sistemas relacionados son plenamente relacionales y capaces de un uso temporal/al estilo de eventos.
  • Surgen preocupaciones bitemporales: algunas herramientas solo registran el tiempo de transacción, no el verdadero “tiempo del evento”.

Beneficios percibidos / casos de uso adecuados

  • Se cita como buen encaje para: analítica/logging, datos financieros o de estilo journal, flujos de trabajo complejos, sincronización entre múltiples sistemas, depuración de comportamiento pasado y la capacidad de reconstruir o reinterpretar vistas derivadas.
  • Algunos informan éxito combinando event sourcing, DDD, CQRS, microservicios y proyecciones en almacenes relacionales/de búsqueda.
  • Otros argumentan que una base de datos relacional simple, más tablas de historial auxiliares o logs de auditoría, basta para la mayoría de los productos.

Críticas, riesgos e historias de fracaso

  • Muchos ven el event sourcing como algo de nicho y sobreutilizado; a menudo, una “solución en busca de un problema”.
  • Puntos de dolor comunes:
    • Alta complejidad en depuración, mapeo/reducción de eventos a estado, mantenimiento y evolución del esquema.
    • Agregaciones lentas que llevan a vistas cacheadas/materializadas, con retraso y problemas de consistencia eventual.
    • Conflictos de GDPR y retención de datos con registros inmutables.
    • Coste de almacenamiento e infraestructura cuando “nunca borrar eventos” se combina con vidas útiles largas.
  • Una historia detallada de desastre: un sistema ES+CQRS con proyecciones en Elasticsearch, sin borrado, coste enorme, importación extremadamente lenta y solo unos pocos usuarios—ahora se está revirtiendo hacia diseños relacionales ACID más simples.

Patrones de implementación discutidos

  • Esquema típico de event store en SQL: id de evento, id de agregado, secuencia/versión, tipo, timestamp, payload JSONB; indexado por agregado y a veces por campos JSON.
  • Uso de snapshots para evitar reproducir todo el historial; proyecciones a múltiples modelos de lectura (relacional, clave-valor, búsqueda).
  • Algunos abogan por tratar la base de datos relacional como una “caché” sobre un log de eventos; otros invierten la idea y simplemente añaden tablas de eventos/logs de auditoría a un sistema principalmente relacional.
  • Para problemas de estilo workflow, se mencionan motores de workflow duraderos (p. ej., Temporal/durable functions) como alternativas que internamente usan event sourcing.

Meta: dinámica de votación en HN

  • Los comentaristas señalan que la publicación llegó a la cima de HN con comentarios mayoritariamente negativos, atribuyéndolo a upvotes impulsados por el título, a la imposibilidad de votar en contra las publicaciones y a personas que votan a favor para mantener visible la discusión.