Recentemente comecei a estudar mensageria e arquitetura orientada a eventos, principalmente utilizando dois serviços do Azure: Azure Service Bus e Azure Event Grid.

No início, confesso que achei o assunto um pouco complicado.

A primeira pergunta que veio à minha cabeça foi:

"Para que eu usaria isso?"

Conforme fui estudando, percebi que a melhor forma de entender esses serviços não era começar pelas ferramentas, mas pelo problema que elas tentam resolver.

E foi a partir daí que comecei a entender melhor o conceito de mensageria.

O que é mensageria?

De forma simplificada, podemos pensar em mensageria como uma forma de permitir que diferentes partes de um sistema troquem informações de maneira desacoplada, sem necessariamente precisarem executar tudo ao mesmo tempo.

Imagine uma aplicação que recebe uma compra.

Sem uma arquitetura assíncrona, poderíamos ter algo parecido com:

Cliente
 ↓
API
 ↓
Processa compra
 ↓
Gera nota
 ↓
Envia e-mail
 ↓
Atualiza outros sistemas
 ↓
Resposta para o cliente

O problema é que a API pode acabar ficando responsável por várias tarefas.

Se uma dessas etapas demorar ou falhar, isso pode afetar toda a operação.

Agora imagine separar essas responsabilidades:

Cliente
 ↓
API
 ↓
Mensagem
 ↓
Processamento assíncrono

A aplicação consegue receber a solicitação e deixar determinadas tarefas para serem processadas posteriormente.

É aí que conceitos como filas, mensagens e eventos começam a fazer sentido.

Azure Service Bus

O Azure Service Bus é um serviço de mensageria voltado para cenários em que precisamos trabalhar com mensagens e processamento assíncrono confiável.

Uma forma simples de pensar é:

"Existe um trabalho que precisa ser processado."

Por exemplo, imagine uma transferência bancária.

A aplicação pode registrar a transferência e publicar uma mensagem:

Transferência realizada
      ↓
Azure Service Bus
      ↓
Consumer
      ↓
Atualiza histórico

O consumidor pode processar essa mensagem posteriormente.

Isso ajuda a reduzir o acoplamento entre os componentes e permite que o produtor da mensagem não precise esperar todo o processamento terminar.

Além disso, o Service Bus possui recursos importantes para cenários de processamento, como:

• Filas;
• Topics e subscriptions;
• Retry;
• Dead Letter Queue (DLQ);
• Controle de concorrência;
• Ordenação em cenários específicos;
• Persistência das mensagens.

Mas existe um detalhe importante:

usar uma fila não significa que podemos simplesmente esquecer os problemas de processamento.

Em sistemas distribuídos, uma mensagem pode ser entregue novamente, por exemplo.

Por isso, conceitos como idempotência também são importantes.

Se uma mesma mensagem for processada duas vezes, o sistema precisa ser projetado para evitar efeitos duplicados quando isso for necessário.

Azure Event Grid

Já o Azure Event Grid trabalha com uma ideia um pouco diferente.

Aqui, podemos pensar:

"Algo aconteceu."

Por exemplo:

Arquivo enviado
    ↓
Event Grid
    ↓
Evento publicado
    ↓
Serviços interessados reagem

Imagine que um usuário faça upload de um arquivo para o Azure Storage.

O upload aconteceu.

Esse acontecimento pode gerar um evento que será encaminhado para sistemas interessados.

Por exemplo:

Azure Storage
    ↓
"Arquivo criado"
    ↓
Event Grid
    ↓
Azure Function
    ↓
Processamento

O objetivo principal aqui não é simplesmente colocar uma tarefa em uma fila para alguém executar.

A ideia é comunicar que determinado evento aconteceu, permitindo que outros componentes reajam a esse acontecimento.

Então qual é a diferença?

Uma forma que me ajudou bastante a diferenciar os dois foi pensar assim:

Event Grid

"Algo aconteceu."

Service Bus

"Existe um trabalho que precisa ser processado."

Essa é uma simplificação, mas ajuda bastante a criar uma primeira visão sobre os serviços.

Por exemplo:

Event Grid

Arquivo foi criado
Pedido foi atualizado
Recurso foi criado

Service Bus

Processar pedido
Enviar uma tarefa para processamento
Executar uma operação posteriormente

Isso não significa que os serviços são concorrentes ou que devemos sempre escolher apenas um deles.

Na verdade, eles podem trabalhar juntos.

Event Grid + Service Bus

Um cenário interessante seria:

Azure Storage
    ↓
 Event Grid
    ↓
 Service Bus
    ↓
 Consumer
    ↓
 Processamento

Imagine novamente o upload de um arquivo.

O Azure Storage gera o evento:

"Um arquivo foi criado."

O Event Grid pode encaminhar esse evento.

O Service Bus pode então ser utilizado para organizar o processamento da tarefa.

O consumidor recebe a mensagem e realiza o processamento.

Dessa forma, podemos separar melhor as responsabilidades:

Event Grid → comunicação de eventos

Service Bus → processamento de mensagens

Essa combinação foi uma das coisas que mais me ajudou a entender por que esses serviços existem.

E se não usarmos mensageria?

Para entender melhor a utilidade dessas tecnologias, também achei importante pensar nos problemas que podem aparecer quando fazemos tudo de maneira síncrona.

Imagine uma compra:

Cliente
 ↓
API
 ↓
Pagamento
 ↓
Nota fiscal
 ↓
E-mail
 ↓
Outros serviços

Se a API precisar esperar todas essas etapas terminarem, uma falha em qualquer serviço pode afetar a resposta final.

Por exemplo, o pagamento pode ter sido realizado, mas o serviço responsável por outra etapa pode estar indisponível.

Isso pode gerar situações difíceis de tratar.

Com uma arquitetura assíncrona, determinadas responsabilidades podem ser desacopladas:

Cliente
 ↓
API
 ↓
Mensagem
 ↓
Processamento

Assim, determinadas tarefas podem ser processadas posteriormente e mecanismos como retry e Dead Letter Queue podem ajudar no tratamento de falhas.

É importante destacar que mensageria não resolve automaticamente problemas como pagamentos duplicados.

Para isso, ainda precisamos pensar em coisas como:

• Idempotência;
• Identificadores únicos de operação;
• Controle de estado;
• Transações;
• Tratamento de falhas.

Ou seja, mensageria é uma ferramenta dentro de uma arquitetura maior.

Um ponto importante: mensageria não é apenas "mandar mensagem"

Antes de estudar esse assunto, eu tinha uma visão muito simples de mensageria.

Pensava basicamente:

"Um sistema manda uma mensagem e outro recebe."

Mas existe muito mais por trás disso.

Quando começamos a trabalhar com sistemas distribuídos, aparecem questões como:

• E se o consumidor estiver offline?
• E se a mensagem for processada duas vezes?
• E se o processamento falhar?
• E se várias mensagens chegarem ao mesmo tempo?
• E se o consumidor não conseguir processar uma mensagem?
• Quando devemos tentar novamente?
• Quando uma mensagem deve ir para uma Dead Letter Queue?
• Como garantir que uma operação não seja executada duas vezes?

Essas perguntas mostram que trabalhar com mensageria também envolve pensar em confiabilidade, escalabilidade e resiliência.

O que ficou da minha primeira experiência estudando mensageria

Depois de estudar esses conceitos, minha visão mudou bastante.

No começo, eu olhava para Service Bus e Event Grid e pensava:

"Por que eu precisaria disso?"

Agora consigo enxergar o problema que eles ajudam a resolver.

Minha forma mais simples de lembrar é:

EVENT GRID
"Algo aconteceu."

      ↓

SERVICE BUS
"Existe um trabalho para processar."

E, em determinados cenários:

Algo aconteceu
    ↓
Event Grid
    ↓
Service Bus
    ↓
Processamento assíncrono

Ainda tenho muito para estudar sobre o assunto, principalmente retry, idempotência, Dead Letter Queue, concorrência, Topics e Subscriptions.

Mas essa primeira etapa foi importante para perceber algo que tenho aprendido cada vez mais no desenvolvimento Back-End:

Não basta conhecer uma tecnologia. É importante entender qual problema ela foi criada para resolver.

Esse foi o principal aprendizado que levei do meu primeiro contato com Azure Service Bus e Azure Event Grid.

Tecnologias estudadas

• C#
• .NET
• Microsoft Azure
• Azure Service Bus
• Azure Event Grid
• Arquitetura orientada a eventos
• Mensageria
• Processamento assíncrono

#Azure #DotNet #CSharp #Backend #Mensageria #AzureServiceBus #AzureEventGrid #SoftwareArchitecture #CloudComputing