O antipadrão mais comum na transição de um Monolito para Microsserviços é a criação de um "Monolito Distribuído". Isso ocorre quando o Serviço A precisa chamar o Serviço B via HTTP (REST/gRPC) para completar uma ação.
Se o Serviço B cair, o Serviço A também falha. Você adicionou a latência da rede e multiplicou os pontos de falha. A cura para esse acoplamento temporal é a Arquitetura Orientada a Eventos (EDA).
Coreografias e Eventos
Numa arquitetura orientada a eventos, os serviços comunicam-se emitindo "fatos" que ocorreram no passado (Eventos). O emissor (Producer) não sabe quem vai consumir a mensagem (Consumer), nem se importa.
Imagine um e-commerce:
// Evento: OrderCreated
{
"event_id": "evt_987xyz",
"type": "order.created",
"timestamp": "2026-03-12T10:00:00Z",
"payload": {
"order_id": "ord_123",
"customer_id": "cus_456",
"total_amount": 150.00
}
}
Ao emitir este evento num Message Broker (como Apache Kafka ou RabbitMQ), múltiplos serviços podem reagir simultaneamente:
- O Serviço de Pagamento processa a cobrança.
- O Serviço de Estoque reserva o produto.
- O Serviço de E-mail envia o recibo.
Se o Serviço de E-mail estiver fora do ar, o pedido não é impactado. A mensagem fica retida no broker até o serviço voltar à vida e processar o "backlog". Isso é Resiliência por design.
O Trade-off da Consistência Eventual
Na EDA, abrimos mão das transações ACID clássicas em prol da disponibilidade. O banco de dados do Serviço A e o banco do Serviço B não serão atualizados no mesmo milissegundo. O sistema estará em Consistência Eventual.
Lidar com falhas em transações distribuídas requer padrões como a Saga Pattern. Se o Pagamento falhar após o Estoque ter reservado o item, você deve emitir um evento compensatório (PaymentFailed) para que o Estoque reverta a reserva.
Filas (Queues) vs Streams (Logs)
Muitos desenvolvedores confundem RabbitMQ com Kafka.
- RabbitMQ (Message Broker): Funciona como uma agência de correios inteligente. Uma vez que o consumidor lê a mensagem, ela é apagada da fila. Ideal para processamento de tarefas em background (Task Queues).
- Kafka (Event Streaming): Funciona como um Log imutável (append-only). Os eventos permanecem gravados no disco por dias ou meses. Ideal para Event Sourcing, análise de dados em tempo real e re-hidratação de bancos de dados a partir do zero.
Se for escalar, abrace os eventos. Deixe os serviços trabalharem no seu próprio ritmo.