Passando de dados relacionais para eventos
Defensores do event sourcing argumentam que armazenar cada mudança como um fluxo imutável de eventos pode preservar o histórico de negócio, permitir análises poderosas e desacoplar serviços, mas muitos engenheiros neste thread veem isso como um padrão nichado e superutilizado que frequentemente adiciona complexidade sem benefício claro. Comentadores enfatizam que bancos de dados relacionais já suportam capacidades temporais e de auditoria, e que a maioria dos sistemas “event-driven” bem-sucedidos na prática ainda depende de stores SQL convencionais ou projeções para consulta e consistência. O consenso emergente é que o event sourcing é valioso para domínios específicos como finanças, analytics ou workflows complexos, mas é uma má substituição padrão para modelos relacionais baseados em CRUD.
Sentimento geral sobre o artigo
- Muitos leitores acharam o artigo pouco claro, excessivamente confiante e estilisticamente irritante.
- Crítica principal: ele sugere que o event sourcing deveria “substituir” abordagens CRUD/relacionais sem explicar rigorosamente os trade-offs, prós/contras ou passos concretos de migração.
- Alguns gostaram da direção geral (pensar em eventos/comportamentos), mas acharam o texto uma introdução superficial ou confusa.
Event sourcing vs bancos de dados relacionais/temporais
- Vários comentaristas enfatizam que event sourcing e o modelo relacional são ortogonais: é possível fazer event sourcing em cima de bancos SQL.
- Bancos de dados relacionais já suportam padrões temporais (por exemplo, tabelas de auditoria, journals, recursos do SQL:2011).
- Datalog e sistemas relacionados são observados como totalmente relacionais e capazes de uso temporal/baseado em eventos.
- Surgem preocupações bitemporais: algumas ferramentas rastreiam apenas o tempo da transação, não o verdadeiro “tempo do evento”.
Benefícios percebidos / casos de uso adequados
- Bons encaixes citados para: análise/logging, dados financeiros/estilo journal, workflows complexos, sincronização entre múltiplos sistemas, depuração de comportamento passado e capacidade de reconstruir ou reinterpretar views derivadas.
- Alguns relatam sucesso combinando event sourcing, DDD, CQRS, microservices e projeções em stores relacionais/de busca.
- Outros argumentam que um banco relacional simples com tabelas auxiliares de histórico ou audit logs basta para a maioria dos produtos.
Críticas, riscos e histórias de fracasso
- Muitos veem event sourcing como nichado e superutilizado; muitas vezes, uma “solução em busca de um problema”.
- Pontos de dor comuns:
- Alta complexidade em depuração, mapeamento/ redução de eventos em estado, manutenção e evolução de schema.
- Agregações lentas levando a views em cache/materializadas, com atraso e problemas de consistência eventual.
- Conflitos com GDPR e retenção de dados por causa de logs imutáveis.
- Custo de storage e infraestrutura quando “nunca apagar eventos” encontra tempos de vida longos.
- Uma história de guerra detalhada: um sistema ES+CQRS com projeções no Elasticsearch, sem exclusão, custo enorme, importação extremamente lenta e apenas alguns usuários — agora sendo revertido para designs relacionais ACID mais simples.
Padrões de implementação discutidos
- Esquema típico de event store em SQL: event id, aggregate id, sequence/version, type, timestamp, payload em JSONB; indexado por aggregate e às vezes por campos JSON.
- Uso de snapshots para evitar reexecutar todo o histórico; projeções para múltiplos modelos de leitura (relacional, key-value, search).
- Alguns defendem tratar o banco relacional como um “cache” sobre um event log; outros invertem isso e apenas adicionam tabelas de eventos/audit logs a um sistema primariamente relacional.
- Para problemas no estilo de workflow, são mencionados engines de workflow duráveis (por exemplo, Temporal/durable functions) como alternativas que internamente usam event sourcing.
Meta: dinâmica de votação do HN
- Comentadores observam que o post chegou ao topo do HN com comentários majoritariamente negativos, atribuindo isso a upvotes guiados pelo título, à impossibilidade de dar downvote em submissões e a pessoas votando para manter a discussão visível.