Blog/Artigos · Engenharia
O evento como fato, o desacoplamento por publicação, CQRS, event sourcing e o custo da consistência eventual.
Malachi descreve um livro de memória escrito diante do Alto, no qual se registra o que os justos fizeram: um registro permanente dos fatos, na ordem em que aconteceram, que não se apaga. É a imagem exata do que a arquitetura orientada a eventos coloca no centro do sistema. No modelo comum, um serviço manda no outro: faça isto, salve aquilo, e quem manda precisa saber quem obedece. No modelo de eventos, ninguém manda: cada parte anuncia o que aconteceu, o pagamento foi aprovado, a apólice entrou em vigência, e escreve esse fato no livro de memória do sistema. Quem se interessa lê e reage, por conta própria. O fato registrado, e não a ordem dada, passa a ser o que move o sistema.
A arquitetura comum é orientada a comando: o serviço de pedidos chama o serviço de estoque, chama o de pagamento, chama o de notificação. Quem inicia precisa conhecer todos os que participam e orquestrar a sequência, e adicionar um novo interessado, o serviço de fidelidade quer saber dos pedidos, exige mexer no serviço de pedidos para chamá-lo também. O acoplamento cresce a cada participante, e o serviço que inicia vira um maestro que precisa conhecer a orquestra inteira.
A arquitetura orientada a eventos inverte a direção. O serviço de pedidos não chama ninguém; ele apenas publica um fato, pedido foi realizado, e segue sua vida. Estoque, pagamento, notificação e fidelidade assinam esse fato e reagem cada um por conta própria, sem que o serviço de pedidos saiba que eles existem. Adicionar um novo interessado não toca no publicador: o novo serviço só assina o evento que já é publicado. É o desacoplamento levado ao extremo, o publicador ignora quem o escuta, e é isso que dá à arquitetura de eventos sua flexibilidade de crescer sem que cada parte precise conhecer as outras. O livro de memória registra o fato; quem quiser que o leia.
O publicador ignora quem o escuta. Adicionar um interessado não toca em quem publica: é o desacoplamento levado ao extremo, e a flexibilidade de crescer sem cada parte conhecer as outras.
Um padrão que costuma andar com eventos é o CQRS, a segregação de responsabilidade entre comando e consulta. A ideia é separar o modelo que escreve, que processa comandos e aplica regras de negócio, do modelo que lê, que serve consultas. Parece estranho ter dois modelos para a mesma entidade, mas resolve uma tensão real: o formato ideal para garantir regras de negócio ao escrever raramente é o formato ideal para consultar rápido, e forçar um só modelo a servir aos dois compromete ambos. Com CQRS, o lado da escrita otimiza para consistência e regra; o lado da leitura otimiza para performance de consulta, muitas vezes com dados já pré-formatados para a tela.
CQRS não é obrigatório para eventos, nem eventos exigem CQRS, mas eles se casam bem. Os eventos publicados pelo lado da escrita alimentam a construção dos modelos de leitura: cada fato registrado atualiza uma visão otimizada para consulta. Isso permite ter várias visões de leitura da mesma verdade, uma para o relatório, uma para a tela, uma para a busca, todas alimentadas pelos mesmos eventos. O custo é que essas visões de leitura ficam eventualmente consistentes: há um pequeno atraso entre o fato ser escrito e a visão de leitura refletir. Para muitos casos isso é aceitável e até imperceptível; para outros, onde a leitura precisa refletir a escrita no mesmo instante, CQRS adiciona complexidade sem ganho, e é um exagero.
O event sourcing leva o livro de memória à sua conclusão radical: em vez de guardar o estado atual das coisas, guarda-se a sequência completa de eventos que levou a esse estado. Não se armazena a conta tem saldo de cem; armazena-se depositou cinquenta, depositou setenta, sacou vinte, e o saldo é calculado somando os fatos. O log de eventos, append-only e imutável, vira a fonte única da verdade, e o estado atual é apenas uma projeção derivada dele. É exatamente o sefer zikaron: um registro permanente de tudo que aconteceu, na ordem, que não se apaga nem se sobrescreve.
O ganho é extraordinário para certos domínios. Você tem auditoria perfeita de graça, porque cada mudança é um fato registrado com quando e por quê; pode reconstruir o estado em qualquer ponto do passado, reproduzindo os eventos até ali; pode corrigir um bug e reprocessar o histórico para ver o estado que deveria ter existido; e pode criar novas visões de leitura sobre dados antigos, porque os fatos brutos estão todos lá. Domínios financeiros, contábeis e regulatórios, onde o histórico é sagrado, amam event sourcing. O preço é alto: a complexidade sobe muito, consultar o estado atual exige projeção, mudar o formato dos eventos passados é um problema espinhoso, e a maioria dos sistemas não precisa de tudo isso. Event sourcing é uma ferramenta poderosa e cara, para quando o histórico dos fatos é, ele mesmo, um requisito de negócio.
O log de fatos é a verdade; o estado é derivado. É o sefer zikaron: registro permanente de tudo que aconteceu, que não se apaga nem se sobrescreve.
A arquitetura de eventos cobra um preço que precisa ser encarado de frente. O maior é a consistência eventual: como os assinantes reagem depois, há sempre uma janela em que uma parte do sistema já sabe do fato e outra ainda não. O pedido foi feito, mas o painel de estoque ainda não atualizou. Para muitos casos isso é aceitável; para outros, onde o usuário espera ver o efeito imediato da sua ação, gera confusão, e é preciso desenhar a experiência para lidar com o atraso, o que nem sempre é trivial. Abraçar eventos é abraçar a consistência eventual, e negar isso produz sistemas que prometem imediatismo e entregam inconsistência.
O segundo custo é a depuração. Num sistema de comando, seguir o que aconteceu é seguir a pilha de chamadas. Num sistema de eventos, o fluxo é indireto: A publicou, B reagiu, B publicou outro, C reagiu, e reconstruir a cadeia de causa exige rastreamento e disciplina. Há ainda a escolha entre coreografia, cada serviço reage por conta própria, mais desacoplado mas mais difícil de seguir, e orquestração, um coordenador conduz o fluxo, mais fácil de entender mas com um ponto central. E há as sagas, para manter consistência de uma transação que atravessa vários serviços sem transação distribuída, compensando passos quando algo falha. Nada disso é impossível; tudo isso é complexidade que só se paga quando o desacoplamento e a flexibilidade que os eventos dão valem mais que a simplicidade do comando direto.
A arquitetura de eventos amadurece do comando acoplado ao registro de fatos consciente. No começo é tudo comando direto, serviços que se conhecem e se chamam. Depois vem a publicação de eventos para desacoplar, o primeiro ganho. No meio vêm CQRS onde os padrões de acesso justificam, e sagas para consistência distribuída. No topo é o event sourcing onde o histórico é requisito, com o log como fonte da verdade, e a operação instrumentada para depurar o fluxo indireto. Cada degrau troca acoplamento por flexibilidade, ao preço de mais complexidade, e a maturidade é aplicar cada peça só onde ela se paga.
Eventos conectam este eixo ao anterior. O evento de domínio do DDD é a semente do evento de arquitetura; a divisão em microsserviços quase sempre se comunica por eventos, porque o comando síncrono entre serviços recria o acoplamento que a divisão queria evitar; e a operação da teia de eventos cai sobre a observabilidade e o rastreamento distribuído do eixo de Cloud e Plataforma. O sefer zikaron é a metáfora exata: o valor de registrar o fato, e não só o estado atual, é ter memória do que aconteceu, poder reconstruir, auditar e reagir. Mas nem todo sistema precisa de um livro de memória completo, e a sabedoria está em saber quando o registro dos fatos é um requisito de negócio e quando o estado atual, simples, basta.
A arquitetura orientada a eventos põe o sefer zikaron no centro: cada parte anuncia um fato, e quem se interessa reage, em vez de um serviço mandar no outro. O desacoplamento deixa o sistema crescer sem cada parte conhecer as outras; CQRS separa escrita de leitura; e o event sourcing guarda o log de fatos como fonte da verdade, com auditoria perfeita. Mas o preço é real, consistência eventual e depuração indireta, e cada peça só se paga onde o histórico e o desacoplamento valem a complexidade. A IA devolve a visão e a rastreabilidade do fluxo. Saber quando registrar o fato, e quando o estado atual basta, continua sendo julgamento de arquitetura.
Gerente de Operações, Tecnologia e Infraestrutura (SRE) numa central de registros. Trabalho com tecnologia desde 2009 e com cibersegurança em tempo integral desde 2015, em infraestrutura crítica, fintech e banking. Escrevo sobre o que eu opero: confiabilidade, segurança, governança e IA que passa por gate antes de chegar em produção.
Engenhariaשָׂפָה אֶחָת
O mercado oscilou do monólito para microsserviços e de volta para o monólito modular. Espalhar em serviços dá autonomia e cobra um imposto pesado de rede, consistência e operação. A pergunta madura não é qual está na moda, é quando o preço de espalhar se paga.
Engenhariaפֶּה אֶל פֶּה
Uma API é uma promessa entre quem serve e quem consome, e uma promessa vaga gera integração sofrida. Bom design de API é fala clara: contrato explícito, semântica coerente e evolução que não quebra quem confiou em você. REST, GraphQL e gRPC servem a necessidades diferentes.
