O que é arquitetura orientada por eventos em microsserviços?

Question

Accepted Answer

Em uma **arquitetura orientada por eventos**, os serviços se comunicam **produzindo e consumindo eventos** por meio de um broker (Kafka, RabbitMQ, etc.). Um serviço anuncia que algo aconteceu; serviços interessados reagem — o produtor não os conhece nem espera por eles.

## Como funciona

```text
Order Service ─publish→ [ Event Broker: "order.placed" ]
                              │
            ┌─────────────────┼──────────────────┐
            ▼                 ▼                  ▼
      Inventory         Notification          Analytics
      (reserve stock)   (send email)          (record metric)
```

## Exemplo de carga de evento

```json
{
  "eventType": "order.placed",
  "eventId": "e-9f2c",          // unique → consumers dedupe
  "occurredAt": "2026-06-18T10:00:00Z",
  "data": { "orderId": "42", "total": 99.5 }
}
```

## Benefícios

- **Acoplamento solto** — adicione um novo consumidor sem tocar no produtor.
- **Resiliência** — o broker armazena eventos durante interrupções.
- **Escalabilidade** — os consumidores escalam independentemente.

## Armadilhas

```text
⚠️ Eventual consistency — readers may briefly see stale data
⚠️ Duplicate delivery — make consumers idempotent (use eventId)
⚠️ Ordering — only guaranteed within a partition/queue
⚠️ Hard to trace a flow across many consumers
```

## Por que isso importa

O design orientado por eventos é o que permite adicionar recursos (análises, verificação de fraude, notificações) simplesmente se inscrevendo, sem alterações nos produtores existentes.

Essa extensibilidade e resiliência têm o preço da consistência eventual e depuração mais difícil — o compromisso central que você aceita ao adotar a orientação por eventos.