Software · Mapas de Conteúdo & Guias
Mapa de Decisão de Mensageria: RabbitMQ, Kafka, Service Bus, Event Grid ou Event Hubs?
Framework objetivo para selecionar o motor assíncrono ideal: contraste técnico entre filas AMQP (RabbitMQ, Service Bus), streaming de logs (Kafka, Event Hubs) e distribuição de eventos discretos (Event Grid).
Adotar mensageria assíncrona é crucial para desacoplar serviços e garantir resiliência, mas escolher a tecnologia incorreta resulta em complexidade operacional desnecessária ou custos proibitivos de infraestrutura. Não existe uma solução única: filas tradicionais resolvem problemas profundamente diferentes dos resolvidos por plataformas de streaming de eventos ou barramentos reativos baseados em push.
flowchart TD
Inicio{"Qual é o padrão fundamental de dados?"}
Inicio -- "Comandos / Tarefas pontuais a processar (Queue/Worker)" --> TipoFila{"Precisa de nuvem gerenciada Azure ou controle open source on-premise?"}
TipoFila -- "Nuvem Totalmente Gerenciada" --> ServiceBus["Azure Service Bus<br/>(Transações, Sessões e Dead-Letter nativo)"]
TipoFila -- "Open Source / Auto-hospedado" --> RabbitMQ["RabbitMQ<br/>(AMQP flexível, roteamento complexo com Exchanges)"]
Inicio -- "Streaming contínuo de eventos em alta escala (Milhões/seg)" --> TipoStream{"Workload analítico/telemetria ou integração corporativa?"}
TipoStream -- "Streaming Open Source Global" --> Kafka["Apache Kafka<br/>(Log imutável particionado e replay histórico)"]
TipoStream -- "Ingestão nativa Azure / Big Data" --> EventHubs["Azure Event Hubs<br/>(Ingestão massiva com partition keys)"]
Inicio -- "Notificações discretas de eventos reativos (Serverless Push)" --> EventGrid["Azure Event Grid<br/>(Pub/Sub reativo, HTTP Webhooks e custo por evento)"]
Matriz de Decisão Arquitetural
| Tecnologia | Paradigma Central | Mecanismo de Consumo | Retenção / Replay | Cenário Típico Recomendado |
|---|---|---|---|---|
| RabbitMQ | Fila de Mensagens Tradicional (AMQP) | Competing Consumers (Push / Pull) | Mensagens são deletadas imediatamente após o Ack | Processamento de transações, integração entre microsserviços internos |
| Azure Service Bus | Barramento Empresarial PaaS | Competing Consumers + Sessões | Deletadas após Ack / Suporte a Dead-Letter | Workflows financeiros, compras, garantias estritas FIFO em nuvem |
| Apache Kafka | Log Distribuído Gravado em Disco | Pull coordenado por Consumer Groups | Retenção temporal (dias/anos), permite Replay completo | Telemetria, Event Sourcing, data pipelines em larga escala |
| Azure Event Hubs | Log Distribuído Gerenciado | Pull coordenado por partições | Retenção configurável de 1 a 90 dias | Ingestão em massa de IoT e telemetria para data lakes |
| Azure Event Grid | Roteador Reativo de Eventos | Push direto para Webhooks / Azure Functions | Sem retenção (foco em entrega pontual em milissegundos) | Arquiteturas orientadas a eventos serverless e gatilhos de blob |
Com este mapa em mãos, a equipe evita o erro comum de adotar um cluster Kafka pesado para um cenário onde uma fila leve do Service Bus ou RabbitMQ resolveria a demanda com uma fração do custo operacional.
