Introdução ao Evento Sourcing e CQRS

A Segregação de Responsabilidade de Procura de Evento e Comando (CQRS) tornou-se padrões fundamentais para a construção de sistemas modernos e distribuídos. Quando combinados com arquiteturas sem servidor, esses padrões desbloqueiam escalabilidade, resiliência e auditoria sem precedentes. Este artigo fornece uma exploração completa da implementação de fornecimento de eventos e CQRS em ambientes sem servidor, cobrindo conceitos fundamentais, estratégias práticas de implementação, armadilhas comuns e melhores práticas do mundo real.

A Sourcing de Eventos: Armazenando Mudança como Sequência de Eventos

A Sourcing de Eventos é um padrão de persistência de dados onde cada alteração no estado da aplicação é capturada como um evento imutável. Em vez de armazenar apenas o estado atual, o sistema registra um registro cronológico de eventos. O estado atual pode ser reconstruído reproduzindo esses eventos. Esta abordagem fornece uma trilha de auditoria completa, habilita consultas temporais (por exemplo, "qual era o estado em uma dada data?"), e simplifica a depuração e a conformidade.

Em um contexto sem servidor, o armazenamento de eventos deve ser altamente durável, escalável e de baixa latência. As escolhas comuns incluem AWS DynamoDB, Azure Cosmos DB[, ou Google Cloud Firestore[]. DynamoDB, com seu modo de capacidade on-demand, se encaixa naturalmente em modelos de faturamento sem servidor e pode lidar com fluxos de eventos de qualquer volume. Dados de eventos são normalmente armazenados em uma tabela com uma chave primária que inclui um identificador agregado e um número de versão para garantir a ordenação e indempotência.

O artigo canônico de Martin Fowler sobre Sourcing de Evento continua a ser uma referência definitiva para a compreensão das nuances do padrão.

Estrutura de eventos e esquema

Cada evento deve conter, no mínimo: um tipo de evento, uma data-limite, um identificador agregado, um número de versão e uma carga útil com os dados que foram alterados. Usando um registro de esquema (por exemplo, ]Google Cloud Schema Registry[] ou AWS EventBridge Schema Registry[]]) ajuda a manter a compatibilidade atrasada à medida que os eventos evoluem.

CQRS: Separando leituras de textos

O CQRS (Command Query Responsibility Segregation) desacopla os modelos usados para lidar com comandos (escritas) daqueles usados para lidar com consultas (leituras). Numa arquitetura sem servidor, isto significa implantar funções ou serviços separados: os manipuladores de comandos processam as gravações, frequentemente adicionando eventos à loja de eventos, enquanto os manipuladores de consultas lêem de modelos de leitura otimizados — tabelas tipicamente desnormalizadas, visualizações materializadas ou índices de pesquisa.

Esta separação traz benefícios significativos: as cargas de trabalho de escrita permanecem magras e focadas na validação e persistência de eventos, enquanto os modelos lidos podem ser sintonizados para recuperação rápida, incluindo pré-join, agregação e recursos de pesquisa de texto completo. Os dois lados se comunicam através de mecanismos assíncronos como ] fluxos de eventos[] ou filas de mensagens[ (por exemplo, AWS SQS, Azure Queue Storage, Google Cloud Tasks).

A documentação original de Greg Young CQRS fornece o contexto fundamental para o padrão.

Combinando a Sourcing de Evento e CQRS em Servidores

Quando usados em conjunto, o Event Sourcing e o CQRS formam uma dupla poderosa: comandos produzem eventos armazenados no log de eventos e projeções (ou assinantes) atualizam de forma assíncrona modelos lidos. Plataformas sem servidor se sobressaem neste paradigma orientado por eventos porque abstraem o gerenciamento de infraestrutura e dimensionam automaticamente cada componente com base em carga.

Abaixo está um fluxo típico de sistema de fonte de eventos sem servidor:

  1. Action do usuário desencadeia uma função de comando (por exemplo, um AWS Lambda por trás do API Gateway).
  2. A função de comando valida a entrada, produz um ou mais eventos de domínio, e os adiciona à loja de eventos (DynamoDB, Cosmos DB, etc.).
  3. Após a adição dos eventos, a função publica uma mensagem (por exemplo, para Amazon EventBridge, Azure Event Grid ou Google Pub/Sub) indicando que novos eventos estão disponíveis.
  4. Funções de rejeição subscrevem o fluxo de eventos e atualizam o modelo lido (por exemplo, uma tabela DynamoDB desnormalizada, um índice Elasticsearch, ou um cache como Redis).
  5. Funções de consulta servem pedidos de leitura diretamente do modelo lido, nunca consultando o evento loja.

Este design garante a consistência do evento entre os lados de escrita e leitura, que é um trade-off principal do CQRS. Em muitos domínios de negócios, a consistência eventual é aceitável e até desejável, pois permite maior rendimento e menor latência para leituras.

Exemplo: Gestão de ordens de comércio electrónico

Considere um sistema de ordem. Um usuário coloca uma ordem (comando), que emite um evento [[FLT: 0]]. Uma função de projeção lê esse evento e atualiza um modelo de leitura de resumo de ordem que inclui o nome do produto, quantidade e estado atual. Outra projeção pode atualizar um modelo de leitura de inventário. Se o usuário mais tarde solicitar histórico de pedidos, a função de consulta lê do modelo de resumo pré- construído, evitando entradas ou leituras caras da loja de eventos brutos.

Implementação da Loja de Eventos em Bases de Dados sem Servidores

As opções de design para o armazenamento de eventos impactam diretamente o desempenho e o custo. Com o DynamoDB, uma abordagem comum é usar uma única tabela com uma chave primária composta: (chave de partição) e (chave de sort). Isto permite a recuperação rápida de todos os eventos para um agregado específico em ordem. Armazenar todo o fluxo de eventos em uma única chave de partição garante que operações como snapshotting (salvações periódicas do estado agregado) permaneçam eficientes.

Para cargas de trabalho que exigem consultas cruzadas, considere usar um índice secundário sobre tipo de evento ou timestamp. No entanto, evite digitalizar toda a loja de eventos; tais necessidades são melhor atendidas por modelos de leitura dedicados.

No Azure, o Cosmos DB oferece recursos semelhantes com níveis de consistência configuráveis e indexação automática. O padrão de Sourcing de Eventos do Centro de Arquitetura Azul fornece orientações específicas para essa plataforma.

Concorrencialidade e indemnidade

A escrita simultânea para o mesmo agregado deve ser tratada cuidadosamente. Usando ] optimista controle de concorrência (por exemplo, atualização condicional com verificação de versão no DynamoDB) garante que apenas um comando tenha sucesso por incremento de versão. Em caso de conflito, o comando pode ser re- testado após re- ler os eventos mais recentes. A imunidade é assegurada armazenando um identificador único (por exemplo, um ID de correlação) com cada evento, permitindo que o manipulador de comando detecte duplicações e rejeite- as graciosamente.

Construindo modelos lidos com projeções

Projeções são funções que consomem eventos e atualizam um ou mais modelos lidos. Em servidores sem, eles são melhor implementados como ] funções orientadas para eventos acionadas pelo barramento de eventos. Cada função de projeção deve ser idempotente: se um evento é processado mais de uma vez (por exemplo, devido a uma repetição), a atualização do modelo lido deve produzir o mesmo resultado.

As estratégias comuns para construir modelos lidos incluem:

  • Tabelas desnormalizadas no DynamoDB ou Cosmos DB que espelham os padrões de consulta (por exemplo, todas as ordens para um usuário).
  • Indices de pesquisa em Elasticsearch, Amazon OpenSearch ou Azure Search para pesquisas com texto completo e facetadas.
  • Visões Materializadas usando frameworks de streaming como AWS Kinesis Data Analytics ou Azure Stream Analytics.
  • Caches de memória (por exemplo, ElastiCache, Redis) para consultas de latência ultra-baixa, com invalidação baseada em TTL.

Para evitar acoplamento apertado, as projeções devem ser apátridas e conduzidas exclusivamente pela carga útil do evento. Elas podem ser adicionadas, removidas ou modificadas sem afetar o lado de comando.

Tratamento da coerência e das SAGAs

Um dos maiores desafios de um sistema CQRS/ES é gerenciar a consistência eventual e coordenar transações de negócios multi-passo. Um usuário pode colocar uma ordem, mas o modelo lido pode não refletir essa mudança por algumas centenas de milissegundos. Para as expectativas do usuário síncrono (por exemplo, mostrando uma página de confirmação), o manipulador de comando pode retornar o ID do evento imediatamente enquanto as pesquisas de frontend para a atualização do modelo lido ou se inscreve em um canal WebSocket.

Para processos multi-step que exigem transações distribuídas, o padrão SAGA é a solução preferida. Cada passo na saga emite eventos, e eventos compensadores são armazenados na loja de eventos para desfazer etapas parcialmente concluídas. Funções sem servidor e orquestradores duráveis (por exemplo, Funções AWS Step, Funções Durable Azure, Fluxos de Trabalho Google) podem implementar sagas de forma confiável sem bloqueios de longo prazo.

Tratamento de Erros e Idempotência na Escala

Os ambientes sem servidor estão sujeitos a falhas transitórias e invocações duplicadas. Os manipuladores de eventos devem ser projetados para a idempotência. Armazene uma janela ] de deduplicação (por exemplo, usando o DynamoDB TTL ou um conjunto de Redes) que grava IDs de eventos processados. Se um evento chegar novamente dentro da janela, é ignorado silenciosamente.

Quando um comando falha após adicionar eventos à loja, os eventos já foram escritos. Nesses casos, você pode precisar implementar um evento compensador (por exemplo, ) para reverter o estado. O evento compensador é armazenado como um evento normal e desencadeia uma projeção que desfaz o trabalho.

Além disso, considere filas de letras mortas (DLQs) para eventos que repetidamente falham no processamento. DLQs permitem inspecionar e replay eventos após a correção do problema, sem perder dados.

Desempenho e otimização de custos em sistemas de eventos sem servidor

Enquanto escalas sem servidor automaticamente, o fornecimento de eventos descuidados pode incorrer em altos custos. As áreas de otimização principais incluem:

  • Processamento de lote: Ao projetar eventos, leia e escreva em lotes para minimizar as solicitações do banco de dados. do DynamoDB] pode lidar com até 25 itens de uma vez.
  • Snapshots:] Armazenar periodicamente instantâneos de estados agregados para evitar reproduzir todo o log de eventos em cada leitura. Os instantâneos são armazenados na mesma tabela de armazenamento de eventos com uma versão especial (por exemplo, número de versão precedido por “SNAP”). A lógica de repetição começa então a partir do último instantâneo, reduzindo drasticamente o tempo de leitura.
  • Cache: Cache acessado frequentemente ler dados do modelo no nível da aplicação (por exemplo, usando ElastiCache ou CloudFront com conteúdo dinâmico).
  • Particionamento de eventos: Se usar um sistema pub/sub como EventBridge, eventos de partição por tipo agregado para controlar a taxa de invocação para funções de projeção.

Exemplo: Estratégia de Instantâneos em DynamoDB

Armazenar um instantâneo com a chave de partição = agregadId e ordenar chave = “SNAP#”. A carga útil contém o estado reconstruído completo. Ao recuperar o estado atual, consulte para eventos com chave de ordenação maior do que a versão de instantâneo, reduzindo o número de eventos para processar. Frequência de instantâneo típica é a cada 50-100 eventos ou com base no tempo (por exemplo, a cada 5 minutos).

Testes e Depuração de Sistemas Servidores Sem Fonte de Evento

Teste de arquiteturas orientadas por eventos requer estratégias diferentes das tradicionais sistemas CRUD. Os testes de unidades podem verificar que os manipuladores de comandos produzem os eventos corretos dados. Os testes de integração devem validar que as projeções atualizam corretamente os modelos lidos quando os eventos são publicados. Como as funções sem servidor são apátridas, considere usar emuladores locais (por exemplo, AWS SAM local, DynamoDB Local, EventBridge biblioteca de testes locais) para executar testes em pipelines CI/CD.

Os problemas de depuração da produção beneficiam-se do próprio log de eventos – você pode reproduzir eventos em um ambiente de desenvolvimento para recriar a sequência exata que levou a um bug. Ferramentas como AWS X-Ray] ou Azure Monitor[] ajudam a rastrear invocações de funções entre serviços.

Pistas comuns e como evitá - las

  • Modelagem de domínio inadequada: Nem todos os domínios de negócios se beneficiam com o fornecimento de eventos. Se você precisar de CRUD simples sem requisitos de auditoria, a sobrecarga pode não ser justificada.
  • Eventos excessivamente grandes: Armazenar grandes cargas (por exemplo, documentos inteiros) como um único evento reduz o desempenho. Decompor eventos em mudanças significativas e granulares.
  • Drift de rejeição: Quando os modelos lidos ficam fora de sincronia devido a eventos ou bugs perdidos, você precisa de um mecanismo de repetição. Construa uma função de repetição que possa reprocessar todos os eventos de um determinado ponto no tempo.
  • Ignorando a evolução do esquema: Os eventos são imutáveis, mas os esquemas mudam. Use um registro e uma versão de cada tipo de evento. Projete novas projeções para lidar com várias versões.
  • O frio começa a afetar projeções: As funções de projeção que são invocadas raramente podem sofrer de latência de início frio. Considere usar a concorrência prevista para projeções críticas ou eventos de loteamento em menos invocações.

Exemplo Arquitetônico Real-Mundo

Um aplicativo de negociação financeira construído em AWS Lambda, DynamoDB e EventBridge implementou o fornecimento de eventos para registrar cada ordem comercial. Funções de comando manipularam pedidos de compra/venda e emitiram , , e eventos. Projeções atualizaram uma tabela DynamoDB para o portfólio do usuário e um cluster de pesquisa Elastic para análise de mercado em tempo real. O sistema processou mais de 10.000 eventos por segundo durante o horário de pico, com 99,99% de disponibilidade e latência sub-segundo para consultas de portfólio, graças à fotografização e design eficiente do modelo de leitura.

Essa equipe evitou armadilhas comuns, aplicando o esquema de eventos rígidos (usando Apache Avro) e implementando um pipeline de repetição dedicado que poderia reconstruir todos os modelos lidos do zero em menos de 30 minutos.

Conclusão

Implementando o Sourcing de Evento e o CQRS em arquiteturas sem servidor, as equipes de desenvolvimento podem construir sistemas altamente escaláveis, auditáveis e manutáveis. Ao aproveitar serviços totalmente gerenciados para armazenamento de eventos, roteamento de mensagens e computação, você pode se concentrar na lógica de negócios enquanto a plataforma lida com as preocupações de infraestrutura. Os principais fatores de sucesso incluem modelagem cuidadosa de eventos, projeções idempotentes, otimização de instantâneos e gerenciamento de erros robusto. Com essas práticas no local, o fornecimento de eventos e o CQRS se tornam ferramentas poderosas para lidar com domínios complexos de negócios na nuvem.