Skip to content
Latchkey

O Que É Arquitetura Orientada a Eventos? Reagindo a Coisas Que Acontecem

A arquitetura orientada a eventos (EDA) conecta componentes emitindo e reagindo a eventos em vez de chamarem uns aos outros diretamente.

Em um sistema orientado a eventos, um serviço anuncia que algo aconteceu, um pedido foi feito, um arquivo foi enviado, e outros serviços reagem se lhes interessar. O produtor não conhece nem espera pelos consumidores. Esse acoplamento fraco é poderoso, mas desloca boa parte da complexidade do fluxo de requisição para um comportamento assíncrono que é mais difícil de testar no CI.

Eventos em vez de chamadas

Em vez de o serviço A chamar o serviço B e esperar, A emite um evento para um broker e segue em frente. Qualquer número de consumidores pode se inscrever. O produtor e os consumidores ficam desacoplados no tempo e no conhecimento uns dos outros.

Por que os times escolhem isso

  • Acoplamento fraco: produtores não dependem de consumidores.
  • Extensibilidade fácil: adicione um novo consumidor sem tocar no produtor.
  • Buffer natural: picos são absorvidos pela fila.
  • Resiliência: um consumidor lento não bloqueia o produtor.

As partes difíceis

Fluxos assíncronos são mais difíceis de rastrear e de raciocinar sobre. Não há uma única pilha de chamadas; o comportamento é emergente entre serviços. Ordenação, entrega duplicada e consistência eventual se tornam preocupações reais que você precisa projetar.

Testando fluxos de eventos no CI

Testes unitários cobrem um handler isoladamente, mas verificar um fluxo de eventos de ponta a ponta normalmente exige um broker real ou simulado. O CI muitas vezes sobe um broker como service container, publica eventos de teste e faz asserções sobre o estado resultante, o que é mais lento do que um teste de API síncrona.

Fazendo deploy de produtores e consumidores

Como eventos são um contrato, mudar o esquema de um evento pode quebrar consumidores que foram deployados de forma independente. Eventos versionados e esquemas retrocompatíveis permitem lançar produtores e consumidores separadamente sem um deploy coordenado de uma só vez.

Testes de integração apoiados em broker

Testes de integração que sobem um broker por execução são mais pesados do que testes unitários simples. Runners gerenciados aquecidos (como o Latchkey) absorvem esse custo extra de inicialização para que os testes de fluxo de eventos ainda retornem rapidamente.

Principais conclusões

  • A arquitetura orientada a eventos desacopla componentes por meio de eventos emitidos e consumidos.
  • Ela troca a simplicidade síncrona por flexibilidade e resiliência assíncronas.
  • Esquemas de eventos são contratos, então versioná-los mantém deploys independentes seguros.

Guias relacionados