Event-Driven Architecture - EDA

A Event-Driven Architecture (EDA) tem sido cada vez mais popular devido à sua capacidade de lidar com grandes volumes de dados e eventos em sistemas distribuídos, especialmente por resolver problemas complexos, como fluxos de trabalho não determinísticos e sistemas altamente reativos e responsivos. A evolução de ferramentas, frameworks e serviços baseados em nuvem tornou o desenvolvimento e a implementação da EDA muito mais acessíveis. Como por exemplo: Apache Kafka, Azure event grid, Amazon eventgrid, Google cloud pub/sub, AWS Lambda, entre outros.

A arquitetura orientada a eventos é baseada no processamento assíncrono usando componentes altamente desacoplados que disparam e respondem a eventos. A topologia básica inclui quatro componentes principais:

• Processador de eventos(Event processor): também conhecido como serviço, é a unidade principal de implantação, capaz de disparar e responder a eventos.
• Evento inicializador(Initiating event): um evento que vem de fora do sistema e desencadeia um fluxo de trabalho assíncrono, como a realização de um pedido ou uma reclamação de seguro.
• Evento de processamento(Processing Event): gerado quando o estado de um serviço muda, comunicando essa mudança ao restante do sistema.
• Canal de eventos(Event chanel): o artefato que armazena e entrega eventos desencadeados para os serviços que respondem a eles.

Workflow

A Event-Driven Architecture (EDA) segue um fluxo de trabalho em que os sistemas reagem a eventos disparados de forma assíncrona, sem que haja uma necessidade de uma interação direta e síncrona entre componentes. A essência desse modelo é baseada na ideia de que os eventos (mudanças de estado ou ações) são produzidos e consumidos por diferentes partes da aplicação de forma desacoplada. A seguir, descrevo o workflow detalhado da EDA:

1. Detecção de um Evento (Produção)

Um evento é qualquer ocorrência que pode ser de interesse do sistema. Ele pode ser gerado por diferentes fontes, como uma mudança de estado em uma aplicação, uma ação do usuário, um sensor IoT, uma transação financeira, entre outros.

Exemplo: Quando um cliente realiza uma compra em um e-commerce, isso gera um evento que contém informações sobre o pedido.

Detalhe do Workflow:

1. O sistema detecta um evento relevante (ex: "pedido criado", "produto adicionado ao carrinho", "email cadastrado").
2. Este evento é então registrado e transformado em uma mensagem de evento, contendo os dados necessários (por exemplo, ID do pedido, produtos, valor, etc.).

Ferramentas associadas: sistemas produtores podem ser aplicações backend, gateways de APIs ou microsserviços que detectam mudanças de estado.

2. Publicação do Evento no Barramento

Após a detecção do evento, ele é publicado em um barramento de eventos, uma fila ou um stream de dados para ser distribuído aos sistemas interessados (consumidores).

Exemplo: Um sistema de e-commerce publica um evento "PedidoCriado" no Kafka, ou envia uma mensagem para um tópico no Google Cloud Pub/Sub.

Detalhe do Workflow:

1. O evento é convertido em uma mensagem e publicado em um middleware de mensageria (como Apache Kafka, RabbitMQ, ou um serviço de cloud como AWS EventBridge).
2. O evento pode ser enviado a um tópico ou uma fila, e pode ser armazenado temporariamente para garantir a persistência até que seja consumido.

Ferramentas associadas: Kafka, RabbitMQ, AWS SNS, Google Pub/Sub, Azure Event Grid.

3. Disseminação e Roteamento do Evento

Uma vez publicado no barramento de eventos, o sistema de mensageria é responsável por roteá-lo aos consumidores que estão interessados nesse tipo de evento. O roteamento pode seguir diferentes padrões, como publish/subscribe ou filas de processamento.

Exemplo: Todos os microsserviços que estão interessados em eventos "PedidoCriado" se inscrevem para receber esses eventos e são notificados.

Detalhe do Workflow:

1. O sistema de mensageria garante que todos os serviços ou componentes que se inscreveram para um tópico específico recebam o evento.
2. Em alguns casos, os eventos podem ser roteados a diferentes serviços de acordo com regras personalizadas.

Ferramentas associadas: Apache Kafka, AWS EventBridge, Azure Event Grid...

4. Processamento do Evento (Consumo)

O evento chega a um ou mais consumidores que foram configurados para reagir a esse tipo de evento. Cada consumidor pode realizar diferentes tipos de processamento com base nos dados do evento.

Exemplo: Um microsserviço de faturamento recebe o evento "PedidoCriado" e inicia o processo de geração de fatura, enquanto um serviço de inventário atualiza o estoque.

Detalhe do Workflow:

1. Um ou mais consumidores assíncronos recebem a mensagem do evento e executam ações com base no conteúdo desse evento.
2. O consumo pode ser imediato ou pode seguir um padrão de enfileiramento para balancear a carga de processamento.

Ferramentas associadas: AWS Lambda, Google Cloud Functions, Apache Flink (para processamento de eventos em stream),...

5. Atualizações e Notificações Resultantes

Com base no processamento do evento, outros eventos podem ser gerados ou o estado de um sistema pode ser alterado. Por exemplo, um serviço pode publicar um novo evento como resultado do processamento, criando um encadeamento de eventos.

Exemplo: Após o processamento de um pedido, um evento "PagamentoProcessado" é gerado e publicado no barramento de eventos, ou o sistema de email notifica o cliente que o pedido foi processado.

Detalhe do Workflow:

1. Consumidores podem disparar novas ações ou criar novos eventos como resultado do processamento (por exemplo, eventos de "Pagamento Confirmado", "Entrega Iniciada").
2. Isso pode desencadear novos fluxos de eventos para outros serviços que também consomem eventos resultantes, formando uma cadeia contínua de ações.

Ferramentas associadas: Serviços de notificação (AWS SNS, Firebase), sistemas de email, ou geração de eventos secundários no mesmo barramento.

6. Manutenção do Estado e Persistência

Durante o processamento de eventos, os sistemas podem precisar atualizar o estado de seus dados ou garantir a persistência de informações relacionadas a um evento.

Exemplo: Um microsserviço de inventário atualiza o banco de dados para refletir a diminuição do estoque com base no pedido realizado.

Detalhe do Workflow:

1. O estado dos dados pode ser atualizado com base nos eventos processados. Isso pode ser feito de forma assíncrona, garantindo que o processamento não bloqueie o sistema.
2. Alguns eventos podem ser armazenados em um banco de dados de eventos para recuperação futura ou auditoria.

Ferramentas associadas: Bases de dados orientadas a eventos como Event Sourcing, bancos de dados NoSQL como MongoDB, ou arquiteturas CQRS (Command Query Responsibility Segregation).

7. Monitoramento e Observabilidade

Para garantir o funcionamento correto e a detecção de falhas no processamento de eventos, sistemas de monitoramento e observabilidade são fundamentais. Esses sistemas monitoram o fluxo de eventos, verificando se há atrasos, falhas ou outras anomalias.

Exemplo: O Datadog, Prometheus ou Grafana pode ser usado para monitorar o tráfego de eventos e gerar alertas caso um serviço de consumo não esteja funcionando adequadamente.

Detalhe do Workflow:

1. Ferramentas de observabilidade monitoram o tráfego de eventos, o tempo de resposta dos consumidores, a latência e outros indicadores importantes.
2. Logs detalhados, métricas de eventos e traces de serviços são capturados para permitir a resolução rápida de problemas.

Ferramentas associadas: Datadog, Prometheus, Grafana, OpenTelemetry.

Principais Vantagens do Workflow EDA:

• Desacoplamento: Produtores e consumidores de eventos são desacoplados, o que significa que podem evoluir de forma independente.
• Escalabilidade: EDA permite que eventos sejam processados em paralelo por diferentes consumidores, facilitando a escalabilidade horizontal.
• Resiliência: Como os eventos são processados de forma assíncrona e armazenados temporariamente, o sistema se torna mais resiliente a falhas temporárias.
• Tempo Real: A arquitetura permite reações quase imediatas a mudanças no sistema, proporcionando uma resposta em tempo real a eventos críticos. pub/sub, AWS Lambda, entre outros.

Referências:

Richards, Mark. Software Architecture Patterns. O'Reilly Media, 2015.

Bellemare, Adam. Building Event-Driven Microservices: Leveraging Organizational Data at Scale. O'Reilly Media, 2020.

Richardson, Chris. Microservices Patterns: With Examples in Java. Manning Publications, 2018.