Desvendando o Poder da Comunicação, através de Eventos, EDA(s) com sucesso🚀

Escrito por: Jean Carlos M. da Silva

E aí, pessoal! 👋 Quem nunca se deparou com aquele sistema monolítico que mais parece um emaranhado de fios, onde mexer em uma ponta faz a outra desabar? 🤯 Ou aquela dificuldade imensa de fazer diferentes partes de sistemas complexos conversarem de forma eficiente e sem travar tudo? Pois é, essa é uma dor comum no nosso mundo de desenvolvimento e modernização.

Mas calma, existe uma luz no fim do túnel, e ela se chama Arquitetura Orientada a Eventos (EDA)! ✨

🤔 Mas afinal, o que raios é uma EDA?

Imagine o seguinte: em vez de um componente A chamar diretamente um componente B, que chama C, e assim por diante (criando aquele acoplamento que a gente tanto foge 🏃♀️💨), na EDA, os componentes reagem a “acontecimentos”.

EDA é um paradigma de design de software onde a comunicação entre os componentes do sistema é baseada na produção, detecção, consumo e reação a eventos.

E o que é um evento? Pense nele como um “sinal” de que algo significativo aconteceu ou um estado mudou no sistema. Um cliente atualizou o cadastro? Isso é um evento! Um novo pedido foi criado? Evento! O estoque de um produto ficou baixo? Adivinha? Evento também!

💪 Por que EDAs são TÃO importantes e o “jeito certo” para Microsserviços?

Aqui a mágica acontece! EDAs são cruciais para arquiteturas modernas, especialmente quando falamos de microsserviços, por vários motivos:

1. Desacoplamento Real (Digital Decoupling na veia!): Produtores de eventos não precisam saber quem são os consumidores, nem quantos são. Eles só emitem o “sinal”. Isso dá uma liberdade incrível! 🦋
2. Escalabilidade Independente: Se um tipo de evento começa a ter um volume muito grande, você pode escalar apenas os consumidores daquele evento específico, sem impactar o resto do sistema. Eficiência pura! 📈
3. Resiliência e Tolerância a Falhas: Se um microsserviço consumidor estiver temporariamente indisponível, os eventos podem ser armazenados em um message broker (como Kafka, RabbitMQ) e processados assim que o serviço voltar. Adeus, efeito dominó! 🚫🔗
4. Flexibilidade e Evolução: Adicionar novos microsserviços que reagem a eventos existentes é muito mais simples. Você não precisa alterar os produtores. É o verdadeiro “plug and play”! 🔌
5. Times Autônomos: Facilita o trabalho de equipes diferentes em partes distintas do sistema, cada uma focada em seus domínios (alô, Domain-Driven Design – DDD! 👋) e reagindo aos eventos que lhes interessam.

Quando você pensa em criar microsserviços, a comunicação assíncrona e desacoplada que as EDAs proporcionam é fundamental para evitar que seus “microsserviços” virem um “monólito distribuído”. Ninguém quer isso, né? 😅

🛠️ Ok, curti! Como começo a aplicar EDAs na prática?

Sem querer mergulhar fundo demais hoje (prometo que exploraremos mais em posts futuros!), a ideia central é:

1. Identifique Eventos de Negócio Chave: Pense nos “verbos” do seu domínio. O que acontece? “Cliente Cadastrado”, “Pedido Realizado”, “Pagamento Confirmado”. Use os princípios do DDD para te guiar aqui!
2. Intercepte esses Acontecimentos: No seu código legado ou nos novos serviços, no momento em que esse evento de negócio ocorre, você precisa capturá-lo.
3. Publique os Eventos: Em vez de chamar outro serviço diretamente, você publica esse evento em um “canal” (um tópico no Kafka, por exemplo). Esse evento deve carregar dados suficientes sobre o que aconteceu.

⚠️ Nem tudo são flores: Os Trade-offs das EDAs

Como tudo na vida de arquitetura, existem considerações importantes:

• Complexidade Inicial: Configurar a infraestrutura de mensageria e pensar em termos de eventos pode ser um pouco mais complexo no início.
• Versionamento dos Eventos: À medida que seu sistema evolui, os “contratos” dos seus eventos também podem precisar mudar. Planejar o versionamento é crucial para não quebrar os consumidores.
• Necessidade de Boa Definição Inicial: Eventos mal definidos podem causar mais problemas do que soluções. A clareza do que cada evento significa e quais dados ele carrega é fundamental.
• Padronização de Contrato: Usar padrões como CloudEvents (um projeto da CNCF que eu adoro!) ajuda a garantir que seus eventos sejam interoperáveis e compreensíveis por diferentes partes do sistema.
• Depuração e Rastreabilidade: Pode ser um pouco mais desafiador rastrear o fluxo de uma operação através de múltiplos serviços assíncronos. Ferramentas de observabilidade são suas melhores amigas aqui e a padronização é o centro de tudo né não OpenTelemetry (outro projetinho da CNCF que visa padronização da observabilidade <3)🕵️♂️

🔗 EDAs + Microsserviços + Digital Decoupling = ❤️

A relação é íntima! EDAs são a espinha dorsal para um bom sistema de microsserviços. Elas permitem o Digital Decoupling, que é a estratégia de separar as capacidades digitais em blocos de construção independentes (nossos microsserviços!), permitindo que eles evoluam e escalem de forma independente. A comunicação via eventos é o que cola esses blocos de forma flexível.

Pense na estratégia do Strangler Fig Pattern para modernizar sistemas legados: você começa a construir novas funcionalidades como microsserviços ao redor do legado, e EDAs são perfeitas para interceptar eventos do legado (às vezes com ajuda de ferramentas como Debezium para CDC, mas isso é papo pra depois 😉) ou fazer o legado reagir a eventos dos novos serviços.

💻 Bora pro Código! Exemplos Práticos com C# e .NET

Vamos ver um exemplo simples. Imagine uma API legada, que altera um cliente e um novo microsserviço (um BackgroundService) que precisa ser notificado dessa alteração.

1. O Evento (O “Sinal”)

Primeiro, nosso evento. Ele precisa carregar os dados importantes sobre a mudança.

// Nosso evento de negócio super importante!
public class CustomerChangedEvent
{
    public Guid CustomerId { get; set; }
    public string OldEmail { get; set; } // Exemplo de dado "antes"
    public string NewEmail { get; set; } // Exemplo de dado "depois"
    public DateTime Timestamp { get; set; }

    public CustomerChangedEvent(Guid customerId, string oldEmail, string newEmail)
    {
        CustomerId = customerId;
        OldEmail = oldEmail;
        NewEmail = newEmail;
        Timestamp = DateTime.UtcNow;
    }
}

Importante: Note que o evento carrega o estado que foi afetado e o identificador do cliente. Ele reflete o evento de negócio “Usuário Alterado”.

2. A API Legada (Produtora do Evento)

Aqui, vamos de API Minimal em .NET 9, apenas para brincar um pouco com as novidades. Mas imagine que seja uma API legado em .Net Framework < 4.x hospedada em algum IIS da vida rs. O foco aqui é o que ela está fazendo, ao atualizar um cliente, ela publica o evento.

// --- Em um projeto de API ASP.NET Core (.NET 9) ---
// Simulação de um publicador de eventos (poderia ser Kafka, RabbitMQ, Azure Service Bus, etc.)

public interface IEventPublisher
{
    Task PublishAsync<T>(T eventData);
}

// Simples implementação para demonstração
public class ConsoleEventPublisher : IEventPublisher 
{
    public Task PublishAsync<T>(T eventData)
    {
        Console.WriteLine($"[EVENT PUBLISHED] {typeof(T).Name}: {System.Text.Json.JsonSerializer.Serialize(eventData)}");
        return Task.CompletedTask;
    }
}

// Program.cs ou onde você configura seus endpoints
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddSingleton<IEventPublisher, ConsoleEventPublisher>(); 

// Registra nosso publicador fake
var app = builder.Build();

app.MapPut("/api/v1/customers/{id}", async (Guid id, CustomerUpdateRequest request, IEventPublisher eventPublisher) =>
{
    // 1. Lógica para buscar o cliente no banco de dados (simulado)
    string oldEmailFromDb = $"oldUser@{id.ToString().Substring(0,5)}.com"; // Simulação
    Console.WriteLine($"Updating customer {id}. Old Email: {oldEmailFromDb}, New Email: {request.NewEmail}");

    // 2. Lógica para atualizar o cliente no banco de dados (simulado)
    // ... cliente.Email = request.NewEmail; context.SaveChanges(); ...

    // 3. Criar e publicar o evento DEPOIS que a alteração foi confirmada!
    var customerChangedEvent = new CustomerChangedEvent(id, oldEmailFromDb, request.NewEmail);
    await eventPublisher.PublishAsync(customerChangedEvent);

    return Results.Ok(new { Message = "Customer updated successfully" });
});

app.Run();

// DTO para o request da API
public record CustomerUpdateRequest(string NewEmail);

3. O Novo Microsserviço (Consumidor do Evento)

Um BackgroundService que “ouve” os eventos CustomerChangedEvent.

// --- Em um projeto de Worker Service (.NET 9) ---
// Simulação de um consumidor de eventos
public interface IEventConsumer
{
    void Subscribe<T>(Action<T> handler);
}

// Esta é uma simulação MUITO simplificada. Em um cenário real,
// você usaria a SDK do seu message broker (Kafka, RabbitMQ).
// Para este exemplo, vamos "simular" o recebimento do evento
// chamando diretamente o handler quando o publicador "publica".
// Em um sistema real, o publicador e consumidor são processos separados.

public class CustomerNotificationService : BackgroundService
{
    private readonly ILogger<CustomerNotificationService> _logger;

    // Em um cenário real, injetaríamos um serviço que se conecta ao broker (Kafka, etc.)
    // e nos notifica de novas mensagens.
    // Para este exemplo, vamos apenas simular o "recebimento" de um evento.
    public CustomerNotificationService(ILogger<CustomerNotificationService> logger /*, IEventConsumer eventConsumer */)
    {
        _logger = logger;
        // eventConsumer.Subscribe<CustomerChangedEvent>(HandleCustomerChanged); // Modo ideal
    }

    // Método que seria chamado pelo nosso IEventConsumer real
    public void HandleCustomerChanged(CustomerChangedEvent eventData)
    {
        _logger.LogInformation($"[EVENT RECEIVED] Customer Changed! ID: {eventData.CustomerId}, New Email: {eventData.NewEmail}. Sending notification...");
        // Aqui você faria algo útil:
        // - Enviar um e-mail de notificação
        // - Atualizar um outro banco de dados/cache
        // - Chamar outra API
        // etc.
    }

    protected override async Task ExecuteAsync(CancellationToken stoppingToken)
    {
        _logger.LogInformation("Customer Notification Service is running.");

        // Simulação: Em um sistema real, este loop não existiria desta forma.
        // O BackgroundService estaria ouvindo um tópico do Kafka, por exemplo.
        // Para fins de demonstração, vamos apenas logar que está ativo.
        while (!stoppingToken.IsCancellationRequested)
        {
            // Apenas para manter o serviço "vivo" e mostrar que está rodando.
            // A mágica do HandleCustomerChanged aconteceria via subscrição ao broker.
            await Task.Delay(TimeSpan.FromMinutes(1), stoppingToken);
        }
    }
}

// Para "testar" localmente de forma integrada (e muito simplista):
// Você precisaria de uma forma do ConsoleEventPublisher no projeto API
// "chamar" o HandleCustomerChanged no projeto Worker.
// Isso foge do escopo de EDAs puras (que são desacopladas),
// mas para um teste local rápido, você poderia usar um singleton compartilhado
// ou um mecanismo de comunicação inter-processos local.
// O ideal é testar com um broker de verdade entre eles.

🎬 Conclusão e Próximos Capítulos…

Ufa! 😅 Falamos bastante hoje, né? Espero que tenha ficado claro como as Arquiteturas Orientadas a Eventos não são apenas uma buzzword, mas uma estratégia poderosa para construir sistemas distribuídos mais resilientes, escaláveis e flexíveis – especialmente quando estamos falando de Microsserviços e modernização de legados!

Lembrem-se, o segredo é pensar em termos de “acontecimentos” e como diferentes partes do seu sistema podem reagir a eles de forma independente.

Nos próximos papos, quero mergulhar em um tópico que mencionei de raspão: CDC (Change Data Capture). Veremos como o CDC pode ser um aliado incrível para extrair eventos de bancos de dados legados e alimentar nossas EDAs, dando mais um passo na modernização! 🤯 Fiquem ligados!

E aí, o que acharam?

👉 Como vocês lidam com a comunicação entre domínios e serviços hoje?

👉 Quais os maiores desafios que vocês enfrentam ao tentar desacoplar funcionalidades?

👇 Deixem seus comentários, dúvidas e experiências aqui embaixo! Vamos trocar uma ideia!

#SoftwareArchitecture #EventDrivenArchitecture #EDA #Microservices #DigitalTransformation #DotNet #DotNet9 #CSharp #Kafka #Debezium #CloudNative #CNCF #DDD #DigitalDecoupling #LegacyModernization #TechLeadership #DeveloperCommunity #AgileArchitecture

Abraços e até a próxima! 🤘

Apoio: 5by5 | Soluções em Sistemas