Arquitetura Orientada à Eventos do jeito certo

Vocês já devem usar, conhecer ou pelo menos ter ouvido falar da arquitetura orientada à eventos; mas infelizmente vou ter que começar com uma definição genérica…

Primeiramente ele é um paradigma de programação. Ele é, como o nome diz, orientado à eventos, bem parecido com um efeito de ação e reação, onde alguma coisa importante acontece em seu sistema, o que pode, ou não, iniciar mais algum processo. Tenha por exemplo um sistema de e-commerce que gera um evento quando uma venda é realizada, e um serviço de entrega que informa aos funcionários quais produtos devem ser separados porque acabaram de ser comprados.

Basicamente funciona da seguinte forma:

1- Alguém publica um evento em um barramento/fila.

2- Os serviços interessados consomem os eventos e reagem de alguma forma.

De forma bem simples é isso, você já sabe pelo menos o que é arquitetura orientada à 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.

Agora que estamos todos no mesmo lugar, podemos discutir como usar essa coisa, e por que usá-la.

Como

O mais importante na arquitetura orientada à eventos é o evento. Mas o que é o “evento”? Evento é algo relevante para o seu negócio, como uma venda, um novo cliente, um saque, a publicação de um texto…

Assim que esse evento ocorrer ele deve ser “publicado” em algum lugar (RabbitMQ, Kafka, Google Cloud Pub/Sub…), de onde os demais serviços que compõem o seu sistema podem visualizar esse evento, e por consequência reagir a ele (que por sua vez podem gerar um novo).

Você pode decidir por guardar todos os eventos da história, ou simplesmente os do momento.

Alguns cuidados devem ser tomados quanto à essa implementação:

• Vários serviços devem reagir ao mesmo evento,
• Os consumidores de eventos devem ser independentes,
• Os eventos devem seguir uma estrutura.

Porque

Alguns cenários em que a arquitetura orientada à eventos facilita a vida de nós devs:

• Vários subsistemas devem processar os mesmos eventos.
• Processamento em tempo real.
• Alto volume e alta velocidade de dados.

Agora que sabemos como e porque usar a arquitetura orientada à eventos vamos para a parte que todos estavam esperando, as vantagens e desafios (para não dizer problemas xD).

Benefícios

• Criadores de eventos e consumidores são separados, o que facilita a escalabilidade.
• É fácil adicionar novos consumidores ao sistema.
• Os consumidores podem responder aos eventos imediatamente assim que chegarem.
• Altamente escalonável e distribuído.

Desafios

• Garantir entrega dos eventos, sem eventos sem sistema.
• Ordenação dos eventos (em alguns casos é irrelevante).

Como todas os outros paradigmas, deve-se pesar os prós e contras da arquitetura antes de usá-la e tentar construir um sistema robusto o suficiente para contornar os problemas e extrair o máximo de suas virtudes.