EDA — Arquitetura Orientada a Eventos

EDA — Arquitetura Orientada a Eventos

Nessa postagem tenho como objetivo trazer um resumo do funcionamento de uma de sistemas onde seus componentes se comunicam entre si por meio de eventos, de forma rápida e assíncrona. Espero que o conhecimento aqui exposto auxilie em futuras tomadas de decisões. Vamos lá?!

O que é?

Arquitetura Orientada a Eventos (EDA) é um paradigma de programação. É basicamente o efeito de um ação e reação, onde de acordo com algum acontecimento/evento dentro do sistema pode ou não gerar um novo processo, como o nome já diz: orientado a eventos.

Esse evento pode ser qualquer coisa dentro do sistema, desde um log a ser gerado, um novo registro sendo inserido no banco de dados, o clique de um mouse… Enfim, existem eventos em praticamente todos os ecossistemas técnicos de nosso dia a dia.

Como funciona?

De forma simples, o processo seria dividido nos seguintes passos:

1. Um evento é publicado em um barramento/fila
2. Os serviços interessados consomem e reagem aos eventos

Aprofundando um pouco existem 2 modelos de eventos: o modelo de pub/sub e o modelo de fluxo de evento.

Pub/Sub : a infraestrutura de mensagens acompanha o controle de assinaturas. Quando um evento é publicado, ele envia o evento para cada assinante. Depois que um evento é recebido, ele não pode ser reproduzido e não será exibido para assinantes novos.

Streaming de eventos : eventos são gravados em um registro. Os eventos são ordenados e duráveis. Os serviços não assinam o fluxo, em vez disso, um cliente pode ler a partir de qualquer parte do fluxo. O serviço é responsável por avançar a sua posição no fluxo. Isso significa que um serviço pode reagir a qualquer evento que já tenha sido gerado.

No desenho acima, existe uma etapa central (Event Ingestion) que pode ser um mediador ou um broker de eventos.

Event Ingestion

Mediador

Usada principalmente quando há necessidade de orquestração ou manipulação de etapas no processamento do evento. Tendo como tipos de componentes a fila, mediador, canais e processador (todos de eventos).

Exemplos de implementações : Apache Camel, Spring Integration ou Mule ESB.

Broker

Usada quando se tem um fluxo de eventos simples, onde não há necessidade de orquestração dos eventos. Este componente pode ser centralizado ou federado e contém os canais de eventos usados no fluxo, sendo os canais modelo de filas, tópicos de mensagens ou a combinação deles.

Exemplos de implementações: AWS SQS, Apache ActiveMQ, Apache Kafka.

Padrões

Notificação de evento

O produtor do evento gera um evento e o envia para um broker de eventos, por exemplo, informando que houve uma alteração de endereço. Os interessados neste evento (no caso os consumidores) serão notificados. Neste modelo, os dados relacionados ao evento não estão nele! Diferente do caso da alteração do endereço, o consumidor queria saber qual é o novo bairro e a rua. Para isso, ele deverá realizar uma consulta no sistema que produziu o evento!

Transferência de estado transportado pelo evento

O evento leva os dados relacionados à ele. Neste caso, o consumidor não precisa consultar o produtor para obter mais informações. Com isso, o consumidor não depende de dados de outra aplicação e disponibilidade para fazer o que precisa ser feito, garantindo assim resiliência e disponibilidade no processo executado pelo consumidor, porém isso irá gerar maior complexidade do lado do consumidor por conta de que os dados são de outro domínio.

Fonte de eventos (Event Sourcing)

Modelo muito utilizado para armazenamento de eventos , criando um histórico de eventos. Na prática, isso nos permite realizar auditoria dos dados e retroceder determinado ponto de estado. Como quando existe alguma inconsistência, por exemplo, e é necessário validar o que foi realizado. Com um histórico, também podemos analisar comportamentos e gerar análises de negócio sobre as informações geradas. Este modelo é muito usado com o padrão CQRS (Command Query Responsibility Segregation), que separa escrita de leitura. Nesta mescla dos padrões vocês vão encontrar o event sourcing sendo a fonte de escrita, que muitas vezes possui um Handler, que faz a gestão e distribuição destes dados para bases de consulta. A abordagem de event sourcing hoje é amplamente aplicada e vai desde cases de Internet da Coisas a Data Science.

Quando usar?

• Vários subsistemas devem processar os mesmos eventos.
• Processamento em tempo real com retardo mínimo de tempo.
• O processamento de eventos complexos, como a correspondência de padrões ou agregação em janelas de tempo.
• Alto volume e alta velocidade de dados, como IoT.

Vantagens

• Produtores e consumidores são separados, aumentando a resiliência e desacoplamento.
• Altamente escalável e distribuído.
• Os consumidores podem responder aos eventos imediatamente assim que chegarem, resultando em operações assíncronas.
• Os subsistemas têm exibições independentes do fluxo de evento.
• Entrega contínua.

Desvantagens

Dependendo da situação, estes são pontos negativos:

• Muita concorrência.
• Pode haver perda de informação
• Pode adicionar mais complexidade se mal implementada
• A garantia de entrega é um problema em grandes volumes
• Desafio para a governança de dados e fluxo.

Referências

• https://docs.microsoft.com/pt-br/azure/architecture/guide/architecture-styles/event-driven
• https://labs.bawi.io/arquitetura-orientada-%C3%A0-eventos-do-jeito-certo-f37727999f15
• https://medium.com/devs-javagirl/desenvolvimento-de-sistemas-e-arquitetura-baseada-em-eventos-3a9894f6a70a
• https://garywoodfine.com/event-driven-architecture-node-js/
• https://www.freecodecamp.org/news/understanding-node-js-event-driven-architecture-223292fcbc2d/
• http://nelsonbassetto.com/blog/2013/05/event-driven-architecture-parte-1/

---