Arquitetura Orientada a Eventos (EDA): Entendendo o Estilo e Seus Componentes

Você já tentou entender como é o estilo de arquitetura orientada a eventos (EDA)? O Event Driven Architecture é um estilo de arquitetura que pode ser usado sozinho como arquitetura do seu projeto ou em conjunto de outros estilos de arquitetura, como microsserviços.

Essa arquitetura usa comunicação assíncrona, onde os serviços acionam eventos e outros serviços respondem a eles.

Componentes Principais

Os componentes principais dessa arquitetura são: evento iniciador, event broker, processador de eventos e evento derivado.

1. Evento Iniciador

Como o nome diz, começa todo o fluxo de eventos. Este evento pode ser simples ou complexo, como criar um pedido no e-commerce. O evento iniciador é enviado para o canal de eventos no event broker para processamento.

2. Event Broker

Geralmente, o componente event broker tem várias instâncias em clusters. Cada broker tem os canais de eventos (filas e tópicos) usados nos fluxos de eventos.

Devido à natureza desacoplada e assíncrona desse estilo arquitetural, a topologia do broker utiliza tópicos, trocas de tópicos ou fluxos como modelo de mensagem de publicação e subscrição (pub/sub).

3. Processador de Eventos

Aceita ou não o evento iniciador, realiza uma tarefa específica associada ao processamento desse evento (como salvar o pedido no banco de dados) e em seguida anuncia o que fez para o restante do sistema, enviando um evento derivado, também de forma assíncrona, para o event broker.

Os processadores de evento respondem ao evento derivado, executam um processamento baseado nele e anunciam o que fizeram por meio de novos eventos derivados. O processo continua até que todos os processadores de eventos estejam ociosos e os eventos processados.

---

Exemplo Prático: Sistema de Entrada de Pedidos de Varejo

Consideraremos o fluxo de trabalho de um sistema de entrada de pedidos de varejo:

Os clientes podem fazer pedidos (como pedir um livro). Neste exemplo:

1. O serviço de pedidos recebe um evento iniciador de fazer pedido.
2. Insere o pedido em uma tabela do banco de dados e retorna um ID para o cliente.
3. Em seguida, ele informa para o restante do sistema que criou um pedido por meio de um evento derivado.

Observe que temos três processadores de eventos interessados nesse evento:

• Serviço de Pagamento: tenta realizar o pagamento, e caso aprovado ou negado, comunica o restante dos sistemas.
• Serviço de Estoque: precisa atualizar o estoque para consistência.
• Serviço de Notificação: notifica por e-mail que o pedido foi criado, enviando um evento derivado de e-mail enviado.

É comum que, no estilo arquitetural EDA, alguns eventos não estejam sendo escutados, como o caso do evento derivado e-mail enviado. Isso ilustra a extensibilidade arquitetural desse estilo, pois há a possibilidade de futuros processadores de eventos responderem ao evento derivado, sem que haja qualquer alteração no sistema existente.

O Desdobramento de Eventos

O processador de pagamento também responde ao evento derivado de pedido criado, fazendo a cobrança no cartão de crédito do cliente. Entre os eventos derivados possíveis gerados como resultado da ação do processador, teremos:

• Notificar ao restante dos sistemas que o pagamento foi aplicado.
• Notificar ao sistema que o pagamento foi negado.

O processador de notificação tem interesse no evento de pagamento negado porque, se isso ocorrer, vai enviar um e-mail ao cliente informando que este deve atualizar as informações do cartão de crédito ou escolher um pagamento diferente.

---

Evento vs. Mensagem: Qual a Diferença?

Resposta curta: Sim, é diferente.

Resposta longa:

• Um evento é um aviso para outros sistemas processadores de que algo já aconteceu: "Acabei de fazer um pedido". Ao processar eventos, estamos reagindo a algo que já aconteceu. O evento tem um tipo de comunicação pub/sub (publicação e assinatura), sendo geralmente transmitido para múltiplos processadores de eventos.
• Já uma mensagem é como uma ordem ou consulta: "Aplique o pagamento do pedido". A mensagem remete a algo que tem que ser feito. Ela utiliza comunicação ponto a ponto (um para um) e é direcionada a apenas um processador, quase sempre.

Outra diferença crucial é que o evento não exige uma resposta de quem recebe. Isso reduz a comunicação entre os processadores de eventos, desacoplando ainda mais os sistemas.

---

Conclusão: O Futuro é Reativo e Desacoplado

Dominar a Arquitetura Orientada a Eventos (EDA) vai muito além de escolher as ferramentas certas como Kafka, RabbitMQ ou AWS EventBridge; trata-se de uma mudança de mentalidade jurídica e técnica. Ao migrar de uma comunicação síncrona e engessada para um ecossistema focado em fatos imutáveis (eventos), abrimos as portas para sistemas infinitamente mais resilientes, escaláveis e prontos para o crescimento.

Como vimos no fluxo de um e-commerce, a grande magia da EDA está na sua extensibilidade. A capacidade de plugar um novo serviço no sistema sem tocar ou colocar em risco as regras de negócio já existentes é o sonho de qualquer equipe de engenharia de software. Além disso, entender de uma vez por todas que eventos não são apenas mensagens direcionadas nos permite desenhar fronteiras muito mais limpas entre nossos microsserviços.

Se você está desenhando um sistema que precisa crescer sem fricção, reagir em tempo real e sobreviver a picos de acessos sem um efeito cascata de quedas, a EDA não é apenas uma opção, ela é o caminho.

Leituras Recomendadas para se Aprofundar

Para quem quer dar o próximo passo e ver a teoria na prática, recomendo fortemente a leitura destas duas obras fundamentais:

• Fundamentos da Arquitetura de Software (2ª Edição): Uma Abordagem Moderna de Engenharia — Mark Richards e Neal Ford
• Criando Microsserviços: Projetando Sistemas com Componentes Menores e Mais Especializados — Sam Newman

E no seu cenário atual? Você já utiliza EDA ou ainda sofre com o famoso “monólito distribuído” cheio de requisições HTTP síncronas? Deixe seu comentário abaixo com as suas dores e experiências!