A transição de dados relacionais para eventos

Guia para a transição de dados relacionais para eventos

• Na igreja do event sourcing, os dados de negócio são preservados como eventos sem serem perdidos.
• Eventos representam fatos que aconteceram e são armazenados após cada operação.
• Um fluxo de eventos é a lista de todos os eventos registrados, é imutável, e erros do passado podem ser corrigidos adicionando novos eventos.

1. Encontrar colunas de estado

• Os valores das colunas de estado podem refletir as etapas do ciclo de vida dos dados.
• Por exemplo, um pedido pode ser iniciado, enviado e pago.
• Esses estados podem ser convertidos em eventos como Order Initiated, Order Shipped e Order Paid.

2. Verificar colunas de data

• Colunas de data podem fornecer informações sobre acontecimentos importantes do processo.
• ShipmentDate, DeliveryDate, OrderPlacementDate etc. revelam a terminologia de negócio e podem ajudar a introduzir novos eventos.

3. Analisar a seletividade das colunas

• Colunas nullable podem ser opcionais ou preenchidas mais tarde.
• Colunas obrigatórias devem ser fornecidas no primeiro evento Order Initiated.

4. Procurar tabelas com mais relações de 1 para N

• Em event sourcing, busca-se agrupar dados em torno de processos de negócio para um processamento eficiente.
• Tabelas com muitas relações de 1 para N podem ser candidatas a tipos de stream.

5. Introduzir eventos explícitos

• Ao migrar dados relacionais para eventos, eventos recém-descobertos não devem ser reutilizados durante a importação; é preciso fornecer explicitamente um evento Order Imported.

6. Experimentação e validação

• É preciso testar protótipos em um ambiente seguro, comparar os resultados com o esperado e iterar sem pressa.

Opinião do GN⁺

• O ponto mais importante deste texto é a relevância de uma nova abordagem que preserve os dados de negócio no processo de transição de um banco de dados relacional para event sourcing.
• O que torna este texto interessante é que ele propõe uma forma de entender e aproveitar melhor o ciclo de vida dos dados, saindo do modelo tradicional de gestão de dados.
• Event sourcing pode ajudar não apenas do ponto de vista técnico, mas também a construir um entendimento comum entre as equipes de negócio e de tecnologia.

[GN⁺]

Comentários do Hacker News

• Recomendação de usar PostgreSQL e ferramentas de relatórios FOSS

  • Se o aplicativo já usa PostgreSQL, a recomendação é armazenar os dados de eventos no PostgreSQL e usar ferramentas de relatórios FOSS, como Apache Superset e Metabase.
  • Usa-se PostgreSQL até que os dados cheguem a cerca de 2 TB e, depois disso, decide-se se é necessário manter 2 TB de dados online ou se bastam apenas resumos diários/horários.
  • Em um caso de cliente, estão processando mais de 10 TB de dados e 1.500 eventos por segundo; os dados detalhados ficam online por 2 dias, e o restante é resumido e movido para o S3, podendo ser consultado via Athena SQL.
  • Usa-se AWS RDS Multi-AZ para oferecer failover automático, e um único engenheiro mantém tudo com menos de 5 horas por mês.
  • O PostgreSQL oferece um sistema único para manter os dados em um só lugar, aprender, administrar e escalar.
  • Até pessoas não técnicas conseguem criar gráficos facilmente em sistemas como Metabase ou Preset.
  • O PostgreSQL evolui a cada ano e, se necessário, é possível escalar ainda mais com sistemas compatíveis com PostgreSQL, como Aurora, TimescaleDB e CitusDB.

• Quando faz sentido usar arquitetura orientada a eventos

  • Quando o cliente realiza uma ação específica e espera uma resposta, isso não é orientado a eventos, e sim um padrão de requisição/resposta.
  • Orientação a eventos significa casos que ocorrem de forma não prevista. Por exemplo, quando você faz push de código no GitHub e isso dispara uma build.

• Relato de uma experiência cética com event sourcing

  • Uma equipe considerou event sourcing, mas acabou decidindo não usar, porque não viu benefícios claros e porque havia risco em tentar algo novo.
  • Não houve arrependimento por ter perdido a oportunidade de aprendizado, e isso é visto de forma positiva por não terem mergulhado em um problema complexo sem necessidade.

• A utilidade da modelagem de eventos de domínio

  • A modelagem de eventos de domínio é útil para se comunicar com especialistas do domínio que estão tentando resolver o problema.
  • Ao implementar um sistema que fornece trilha de auditoria para uma máquina de estados ao longo de um longo período, é melhor usar ferramentas como Temporal.io/durable functions.
  • Essas ferramentas usam event sourcing internamente e forçam a escrita de código levando em conta deduplicação e idempotência.

• Pergunta sobre a implementação de event sourcing

  • Falta uma explicação sobre como reconstruir o estado atual com eficiência a partir de um fluxo de eventos e como modelar esse fluxo de eventos no banco de dados.

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

  • A abordagem top-down começa no domínio de negócio e mapeia a implementação para as tecnologias, ferramentas e fornecedores disponíveis.
  • A abordagem bottom-up começa nas tecnologias, ferramentas e fornecedores disponíveis e combina uma solução que funcione.
  • A abordagem customizada inclui DDD, CQRS/ES, Sagas, TBUI, GraphQL, tipos algébricos de dados etc.
  • A abordagem genérica inclui RDBMS, CRUD, REST, transações ACID, CDC, UI administrativa genérica, no-code/low-code, tipos limitados/genéricos etc.

• Apoio e crítica à arquitetura baseada em eventos

  • Há apoio à arquitetura baseada em eventos, mas o artigo em questão falha em transmitir sua argumentação com clareza.
  • Se o foco estiver na diferença entre relações de dados e comportamento de negócio, fica mais claro por que se afastar de um armazenamento relacional operacional.

• Event sourcing e a necessidade de relações

  • Apesar de muitas vantagens do event sourcing, ainda há necessidade de relações.
  • Se toda a relacionalidade estiver apenas implícita no código da camada de aplicação, isso não é aceitável.
  • É necessário um jeito de consultar as relações ou de manter atualizadas as views relacionais.

• Defesa dos dados relacionais

  • Decidiu-se evitar complexidade e permanecer fiel aos dados relacionais tradicionais.

• Nova percepção sobre design orientado a eventos

  • A pessoa conheceu recentemente o design orientado a eventos e, ao pensar na estrutura de dados ideal em um mundo dominado por IA, chegou a uma conclusão parecida.
  • Considera que o design orientado a eventos terá valor se conseguir administrar a complexidade e permitir que os dados sejam realmente utilizados.
  • Espera-se que, nos próximos anos, com a IA podendo consultar o conhecimento sobre todos os eventos de negócio, o design orientado a eventos se torne comum.