Eventos assíncronos

Como funcionam os fluxos assíncronos baseados em eventos: publicação, consumo e processamento entre microsserviços através do Event Bus.

O que é um fluxo assíncrono baseado em eventos

Em um fluxo assíncrono, um serviço publica um evento indicando que algo aconteceu, e outros serviços reagem a esse evento sem que o publicador precise esperar uma resposta. Não há uma conexão direta entre quem produz o evento e quem o consome.

Esse modelo é fundamental em arquiteturas distribuídas porque permite desacoplamento temporal: os serviços não precisam estar disponíveis ao mesmo tempo para se comunicar.

Diferença em relação à comunicação síncrona

Anatomia de um evento

Um evento bem definido contém:

• Tipo: nome que identifica o que aconteceu (OrderPlaced, PaymentCompleted)
• Payload: dados relevantes do fato (ID do pedido, valor, timestamp)
• Metadata: informação de rastreabilidade (correlationId, timestamp, source)
• Versão: para lidar com a evolução do esquema

{
  "type": "OrderPlaced",
  "version": "1.0",
  "timestamp": "2024-01-15T10:30:00Z",
  "correlationId": "abc-123-def",
  "source": "ms-orders",
  "payload": {
    "orderId": "order-456",
    "customerId": "cust-789",
    "totalAmount": 150.00,
    "items": [
      { "productId": "prod-001", "quantity": 2 }
    ]
  }
}

O fluxo completo de um evento

sequenceDiagram
    participant MS1 as Microsserviço Origem
    participant EB as Event Bus
    participant MS2 as Consumidor A
    participant MS3 as Consumidor B
    participant MS4 as Consumidor C

    MS1->>EB: Publicar evento (OrderPlaced)
    Note over MS1: O publicador continua seu trabalho

    EB->>MS2: Entregar evento
    EB->>MS3: Entregar evento
    EB->>MS4: Entregar evento

    MS2->>MS2: Atualizar estoque
    MS3->>MS3: Enviar notificação
    MS4->>MS4: Registrar analytics

Passo 1: Publicação

O microsserviço de origem conclui sua operação principal (por exemplo, criar um pedido) e publica um evento no Event Bus. Uma vez publicado, o serviço não espera que ninguém o processe.

Passo 2: Distribuição

O Event Bus recebe o evento e o distribui para todos os consumidores inscritos. Dependendo da tecnologia (Kafka, RabbitMQ, SNS/SQS), a distribuição pode ser:

• Fan-out: todos os inscritos recebem uma cópia
• Competição: apenas um consumidor do grupo processa cada mensagem
• Combinação: fan-out entre grupos, competição dentro de cada grupo

Passo 3: Consumo

Cada consumidor recebe o evento e executa sua lógica de forma independente. Um consumidor lento não afeta os demais.

Passo 4: Confirmação

O consumidor confirma (acknowledge) que processou o evento corretamente. Se falhar, o Event Bus pode tentar reenviar a entrega.

Padrões de publicação

Publicar depois de persistir

O serviço primeiro salva no seu banco de dados e depois publica o evento. É simples, mas tem um risco: se a publicação falhar após persistir, o evento se perde.

Outbox Pattern

O serviço salva o evento em uma tabela outbox dentro da mesma transação que a operação de negócio. Um processo separado lê a tabela outbox e publica os eventos no bus. Isso garante consistência entre a operação e a publicação.

Event Sourcing

Em vez de salvar o estado atual, salvam-se todos os eventos que produziram esse estado. A publicação é inerente ao modelo.

Desafios dos fluxos assíncronos

Ordem dos eventos

Os eventos podem chegar em ordem diferente daquela em que foram publicados. Os consumidores devem ser capazes de lidar com isso, seja reordenando ou sendo tolerantes à desordem.

Eventos duplicados

O Event Bus pode entregar o mesmo evento mais de uma vez (at-least-once delivery). Os consumidores devem ser idempotentes: processar o mesmo evento duas vezes deve produzir o mesmo resultado que processá-lo uma vez.

Consistência eventual

Os dados entre serviços não estão sincronizados instantaneamente. Depois de publicar um evento, pode passar um tempo até que todos os consumidores reflitam a mudança. O sistema deve ser projetado para tolerar essa janela de inconsistência.

Observabilidade

Rastrear um fluxo assíncrono é mais difícil do que um síncrono. O correlationId é essencial para poder acompanhar a cadeia de eventos através de múltiplos serviços.

Quando usar eventos assíncronos

São adequados quando:

• Múltiplos serviços precisam reagir ao mesmo fato
• Não é necessária uma resposta imediata
• Deseja-se desacoplar serviços para escalar de forma independente
• O processo pode tolerar consistência eventual

Não são adequados quando:

• É necessária uma resposta imediata para o usuário
• A operação exige consistência forte entre serviços
• A complexidade adicionada não se justifica pelo volume ou pelos requisitos

Resumo

Os fluxos assíncronos baseados em eventos permitem que os serviços se comuniquem sem acoplamento direto. O publicador não conhece os consumidores, e cada consumidor processa no seu próprio ritmo. Isso traz escalabilidade e resiliência, mas introduz desafios de ordem, duplicados e consistência que devem ser tratados com padrões como idempotência, outbox e rastreabilidade distribuída.