Mensageria: Kafka, RabbitMQ, AMQP e JMS

Mensageria: desacoplar tempo, capacidade e disponibilidade

Princípio central

Confiabilidade depende do protocolo, do broker e do comportamento correto de produtores e consumidores.

Edição aprofundada - material de estudo e consulta profissional

radio_button_unchecked Apresentação do capítulo

Mensageria é uma das bases de arquiteturas distribuídas. Em vez de exigir que dois sistemas estejam disponíveis ao mesmo tempo e concluam uma interação no mesmo intervalo, um produtor publica uma mensagem em um intermediário e um ou mais consumidores processam essa mensagem quando possuem capacidade. Esse desacoplamento temporal reduz dependências diretas, absorve picos e permite compor fluxos assíncronos de negócio.

A palavra mensageria, porém, cobre modelos diferentes. Uma fila tradicional distribui unidades de trabalho para consumidores e tende a remover ou confirmar mensagens após o processamento. Um log distribuído mantém registros por um período e permite que consumidores independentes avancem seus próprios offsets ou façam replay . Um sistema de publish/subscribe entrega cópias lógicas a vários grupos interessados. Cada modelo altera ordering, retenção, escalabilidade e recuperação.

Kafka e RabbitMQ são frequentemente comparados como concorrentes, mas nasceram com ênfases distintas. Kafka organiza eventos em tópicos particionados e persistentes, otimizados para retenção, replay e alto throughput. RabbitMQ é um broker de mensageria com roteamento flexível por exchanges, filas, acknowledgements e diferentes tipos de fila. AMQP pode significar tanto o modelo 0-9-1 associado ao RabbitMQ quanto o protocolo padronizado AMQP 1.0. JMS, hoje Jakarta Messaging, é uma API Java e não um broker ou protocolo único.

Este capítulo constrói um modelo mental que começa em mensagens, confirmação, ordering e idempotência ; aprofunda Kafka e RabbitMQ; diferencia AMQP 0-9-1 de AMQP 1.0; explica a abstração JMS; e encerra com padrões de integração, segurança, observabilidade, capacidade e troubleshooting . O objetivo é permitir decisões técnicas conscientes, não apenas ensinar comandos de um produto.

Como estudar este capítulo

Para cada fluxo, escreva quem produz, onde a mensagem fica armazenada, como o broker confirma recebimento, quando o consumidor confirma processamento, qual é a unidade de ordering e como duplicatas serão tratadas. Sem essas respostas, a promessa de entrega permanece ambígua.

Objetivos de aprendizagem

• Explicar por que mensageria desacopla tempo, capacidade e disponibilidade entre sistemas.
• Distinguir fila, tópico, log distribuído, publish/subscribe e stream .
• Compreender acknowledgements, confirms, offsets e semânticas de entrega.
• Relacionar ordering, partições, consumer groups, retries e idempotência .
• Descrever a arquitetura do Kafka, incluindo tópicos, partições, réplicas, líderes e KRaft .
• Descrever a arquitetura do RabbitMQ, incluindo exchanges, queues, bindings, vhosts e channels.
• Diferenciar AMQP 0-9-1 e AMQP 1.0.
• Explicar Jakarta Messaging/JMS como API de programação e abstração de provider.
• Projetar DLQ, retry , Outbox, Inbox, request -reply e competing consumers.
• Aplicar segurança, observabilidade, planejamento de capacidade e troubleshooting .

Estrutura do capítulo

• 31.1 Fundamentos de mensageria e desacoplamento
• 31.2 Fila, publish/subscribe, stream e log distribuído
• 31.3 Mensagens, envelopes, headers e contratos
• 31.4 Acknowledgements, confirms e semânticas de entrega
• 31.5 Ordering, partições, idempotência e duplicatas
• 31.6 Kafka: arquitetura, produtores e consumidores
• 31.7 Retenção, compactação, replay , Connect e Streams
• 31.8 RabbitMQ: exchanges, filas, bindings e routing
• 31.9 Confiabilidade, quorum queues, streams , DLX e prefetch
• 31.10 AMQP 0-9-1 e AMQP 1.0
• 31.11 Jakarta Messaging/JMS
• 31.12 Padrões de integração, segurança, observabilidade e troubleshooting
• Resumo, checklist, exercícios, glossário e referências

radio_button_unchecked 31.1 Fundamentos de mensageria e desacoplamento

Em uma chamada síncrona, o consumidor depende da disponibilidade e do tempo de resposta do provedor. Em um fluxo assíncrono, o produtor transfere a responsabilidade imediata para um broker ou log , recebe uma confirmação apropriada e segue seu processamento. O consumidor pode trabalhar depois, respeitando sua própria capacidade. Essa diferença altera a arquitetura de falhas: indisponibilidade temporária do consumidor não precisa impedir a publicação, desde que o broker possua armazenamento e capacidade suficientes.

O desacoplamento não é absoluto. Produtores e consumidores continuam compartilhando contrato, semântica, expectativa de prazo e regras de negócio. Uma mensagem pode estar tecnicamente entregue e ainda ser semanticamente inválida. Um consumidor pode confirmar cedo demais e perder trabalho, ou confirmar tarde demais e provocar duplicatas. Por isso, mensageria precisa de contrato, ownership, observabilidade e estratégia de recuperação.

A decisão entre síncrono e assíncrono deve observar o significado do resultado. Consultas que precisam responder imediatamente ao usuário normalmente permanecem síncronas. Processos longos, integração com múltiplos sistemas, absorção de picos e propagação de eventos se beneficiam de assincronicidade. Muitos fluxos combinam ambos: uma API aceita o comando, persiste estado e publica um evento; o cliente acompanha a conclusão por consulta, callback ou canal de notificação.

radio_button_unchecked 31.2 Fila, publish/subscribe, stream e log distribuído

Fila é uma estrutura em que mensagens aguardam consumidores. No padrão competing consumers, várias instâncias compartilham a fila e cada mensagem é processada por apenas uma delas. Publish/subscribe cria múltiplas assinaturas ou filas lógicas para que grupos diferentes recebam o mesmo evento. O termo tópico pode representar uma entidade de roteamento, uma categoria de publicação ou um log particionado, dependendo da tecnologia.

Kafka trata um tópico como um log dividido em partições. Registros permanecem conforme políticas de retenção ou compactação, e consumidores registram offsets. Isso permite replay , múltiplos grupos independentes e reconstrução de projeções. RabbitMQ usa exchanges para rotear mensagens a filas ou streams ; consumidores normalmente recebem de filas e confirmam processamento. Streams do RabbitMQ acrescentam retenção e leitura por offset , aproximando-se de casos de log .

Escolher o modelo correto é mais importante do que escolher o produto por marca. Trabalho exclusivo e comandos direcionados combinam bem com filas. Eventos de domínio destinados a vários consumidores pedem fan-out ou grupos independentes. Histórico reprocessável, analytics e event streaming favorecem logs . Um sistema pode usar mais de um modelo ao mesmo tempo.

Fila tradicional e log distribuído preservam estados diferentes

radio_button_unchecked 31.3 Mensagens, envelopes, headers e contratos

Uma mensagem possui payload e metadados. O payload carrega o dado de negócio; headers ou properties carregam informações como tipo, versão, correlation ID, content type, timestamp, trace context, prioridade, expiração e chave de particionamento. Misturar metadados de transporte com regras de negócio dificulta migração entre brokers e pode criar dependência excessiva de uma biblioteca específica.

Contratos de eventos precisam definir semântica, não apenas JSON . O nome do evento deve indicar algo que ocorreu, como PagamentoAutorizado, e não uma instrução ambígua. O schema precisa informar campos obrigatórios, nullability, tipos, unidades, precisão, identificadores e compatibilidade. Avro, JSON Schema e Protobuf são opções comuns, mas a governança depende de regras de evolução, catálogo e testes.

Envelopes padronizados facilitam correlação e observabilidade. Entretanto, replicar toda a entidade em cada evento pode expor dados desnecessários e aumentar acoplamento. Publicar apenas um identificador pode obrigar consumidores a fazer chamadas síncronas. A decisão deve equilibrar autonomia, privacidade, tamanho, consistência e frequência de mudança.

Exemplo conceitual de envelope de evento

{
  "specversion": "1.0",
  "type": "pagamento.autorizado.v1",
  "id": "evt-7f8d2a",
  "source": "servico-pagamentos",
  "time": "2026-07-16T11:30:00Z",
  "subject": "pagamento/93842",
  "data": { "pagamentoId": "93842", "valor": 149.90 }
}

radio_button_unchecked 31.4 Acknowledgements, confirms e semânticas de entrega

Confiabilidade precisa ser analisada por trecho. O produtor envia ao broker e precisa saber se a mensagem foi aceita com o nível de durabilidade requerido. Depois, o broker entrega ao consumidor e precisa saber se o processamento terminou. Publisher confirms e consumer acknowledgements resolvem essas duas relações separadas. Um confirm do broker não prova que o consumidor concluiu a regra de negócio.

At-most-once aceita a possibilidade de perda para evitar repetição: a mensagem pode ser considerada concluída antes do processamento. At-least-once privilegia não perder, mas aceita duplicatas quando há falha após o efeito de negócio e antes do acknowledgement . Exactly-once é uma propriedade contextual, normalmente limitada a fronteiras específicas. Não significa que qualquer efeito externo, banco ou API remota será magicamente executado uma única vez.

Em sistemas reais, at-least-once com idempotência é a base mais comum. O consumidor registra um identificador processado ou usa uma operação naturalmente idempotente, executa o efeito e confirma depois. Se a mensagem reaparecer, o mesmo resultado é preservado. Quando o efeito e o registro de deduplicação não compartilham transação, ainda existem janelas de falha que precisam ser tratadas pelo desenho.

radio_button_unchecked 31.5 Ordering, partições, idempotência e duplicatas

Ordering global reduz paralelismo e é caro. A maioria das plataformas preserva ordem apenas dentro de uma fila, partição, canal ou sessão, e mesmo essa ordem pode ser alterada por requeue, prioridade, múltiplos produtores ou processamento concorrente. A arquitetura deve definir qual entidade precisa de ordem: conta, pedido, cliente ou agregado. Essa entidade costuma orientar a chave de particionamento ou o destino da mensagem.

Uma chave estável concentra eventos relacionados na mesma partição, mas pode produzir hot partitions se a distribuição for desigual. Chaves aleatórias melhoram balanceamento, porém perdem ordering por entidade. O consumidor também precisa processar de forma compatível: várias threads sobre a mesma partição podem concluir fora de ordem se não houver coordenação.

Duplicatas surgem em retries de produtor, reentrega após falha, failover e reprocessamento intencional. Idempotência pode usar chave de negócio, versão do agregado, tabela Inbox, compare-and-set, upsert ou controle de sequência. A solução deve definir por quanto tempo a deduplicação é mantida e qual é o comportamento quando uma mensagem antiga reaparece.

Modelo mental

Pergunte sempre: ordem entre quais mensagens, dentro de qual unidade, observada por qual consumidor e durante qual janela? Dizer apenas que o broker preserva ordem é insuficiente.

radio_button_unchecked 31.6 Kafka: arquitetura distribuída

Kafka organiza dados em tópicos particionados. Cada partição é um log ordenado de registros identificados por offsets crescentes. Uma partição possui uma réplica líder que atende leituras e escritas e réplicas seguidoras que acompanham o log . Replicação aumenta tolerância a falhas, mas a durabilidade percebida depende de configurações de produtor, quantidade de réplicas e conjunto de réplicas sincronizadas.

Brokers armazenam partições e atendem clientes. A metadata do cluster é coordenada pelo modo KRaft , baseado em quorum de controladores. A separação entre brokers e controladores pode ser física ou lógica, conforme o porte e a topologia. Planejamento de capacidade considera disco sequencial, page cache , rede, quantidade de partições, replicação, retenção e padrão de acesso.

Tópicos não são filas exclusivas. Vários consumer groups podem ler o mesmo tópico de maneira independente. Dentro de um grupo, cada partição ativa é atribuída a apenas um consumidor por vez, o que limita o paralelismo útil ao número de partições. Adicionar consumidores além desse número não aumenta throughput daquele grupo.

radio_button_unchecked 31.7 Produtores, consumidores, offsets e transações no Kafka

O produtor escolhe tópico, chave, headers e payload . A chave pode determinar a partição, e o batching agrupa registros para melhorar eficiência. A configuração acks controla quando a publicação é considerada concluída. Idempotent producer evita duplicação causada por retries dentro das garantias suportadas pelo protocolo. Isso não torna automaticamente idempotente um consumidor que grava em outro banco.

Consumidores fazem parte de grupos, recebem partições e controlam offsets. Commit antecipado pode perder processamento; commit tardio pode causar reentrega. Rebalances redistribuem partições quando membros entram, saem ou alteram assinatura. Estratégias cooperativas e tratamento correto de revogação reduzem pausas, mas o consumidor precisa finalizar ou interromper trabalho de maneira segura.

Transações Kafka podem agrupar publicações e commits de offsets para pipelines consume-transform-produce dentro do ecossistema Kafka. Com isolation apropriado, consumidores evitam ler registros abortados. A garantia não se estende automaticamente a bancos externos, e-mails ou chamadas HTTP . Para esses efeitos, Outbox, Inbox e idempotência continuam relevantes.

radio_button_unchecked 31.8 Retenção, compactação, replay , Kafka Connect e Kafka Streams

Retenção por tempo ou tamanho remove segmentos antigos independentemente de todos os consumidores terem lido. O dimensionamento precisa garantir que consumidores atrasados não ultrapassem a janela de retenção. Log compaction preserva, de forma eventual, o registro mais recente por chave e é útil para changelogs e reconstrução de estado. Tombstones representam remoções no modelo compactado.

Replay é um recurso poderoso e perigoso. Reposicionar offsets permite reconstruir projeções e corrigir consumidores, mas também pode repetir efeitos externos. Antes de reprocessar, o time deve separar consumidores puramente determinísticos daqueles que enviam e-mail, debitam valores ou chamam terceiros. Ambientes de replay , tópicos de saída separados e dry-run reduzem risco.

Kafka Connect padroniza integração com fontes e destinos por connectors, tasks e offsets. Kafka Streams oferece biblioteca para transformações, joins, janelas e state stores. Esses componentes não eliminam decisões de schema , semântica, partição e tratamento de erros; eles fornecem runtime e abstrações para implementá-las.

radio_button_unchecked 31.9 RabbitMQ: arquitetura, exchanges, filas e bindings

RabbitMQ recebe conexões TCP e multiplexa canais lógicos. Virtual hosts isolam namespaces, permissões e topologias. Em AMQP 0-9-1, publishers publicam em exchanges. A exchange analisa tipo, routing key, headers e bindings para encaminhar a mensagem a uma ou mais filas, streams ou outras exchanges. Uma mensagem não roteada pode ser descartada ou devolvida ao publisher quando o modo mandatory é usado.

Exchanges direct comparam routing keys de forma exata; topic usam padrões hierárquicos; fanout distribuem para todos os bindings; headers usam propriedades da mensagem. Filas armazenam mensagens para consumidores. Durabilidade da fila, persistência da mensagem e replicação são conceitos diferentes: todos precisam estar coerentes com o requisito de sobrevivência a falhas.

Connections são recursos relativamente pesados; channels são usados para multiplexar operações. Abrir um channel por mensagem é antipadrão. Publishers e consumidores de longa duração precisam tratar reconexão, recuperação de topologia, confirms, acknowledgements e fluxo. O broker não substitui lógica de aplicação para deduplicação ou reconciliação.

RabbitMQ AMQP 0-9-1: publicação em exchange e roteamento para filas

radio_button_unchecked 31.10 RabbitMQ: acknowledgements, prefetch , quorum queues, streams e DLX

Consumer acknowledgements podem ser automáticos ou manuais. No modo manual, o consumidor confirma após concluir o trabalho, rejeita sem requeue quando a mensagem é inválida ou pede requeue quando a falha parece temporária. Requeue indiscriminado pode criar loop de redelivery. Prefetch limita a quantidade de mensagens não confirmadas por consumidor e funciona como mecanismo de backpressure e distribuição de carga.

Publisher confirms informam que o broker assumiu responsabilidade pela publicação. Eles são independentes dos consumer acknowledgements. Para alto throughput, aplicações normalmente usam confirms assíncronos e correlacionam sequências, em vez de bloquear após cada mensagem. O uso de transações de channel é possível, mas costuma ter custo maior e não substitui transações de negócio.

Quorum queues são filas replicadas orientadas a segurança de dados e consenso. Classic queues permanecem úteis para casos específicos, mas não são a escolha de alta disponibilidade. Streams e super streams oferecem retenção, replay e particionamento. Dead Letter Exchanges recebem mensagens expiradas, rejeitadas ou excedentes conforme políticas. Poison messages precisam de contagem de tentativas, quarentena e tratamento operacional, não apenas requeue infinito.

radio_button_unchecked 31.11 AMQP 0-9-1 e AMQP 1.0

AMQP 0-9-1 é o modelo de protocolo amplamente associado ao RabbitMQ. Ele define exchanges, queues, bindings, channels e métodos como basic.publish, basic.consume e acknowledgements. AMQP 1.0 é um padrão OASIS diferente: define protocolo binário de wire, sistema de tipos, mensagens, connections, sessions , links, flow control, settlement e outcomes. Compartilhar o nome AMQP não torna as versões interoperáveis diretamente.

No AMQP 1.0, um link é unidirecional entre source e target e possui sender e receiver endpoints . Deliveries podem permanecer unsettled até que as partes concordem sobre o outcome. Créditos de link controlam fluxo. A especificação não obriga uma topologia de broker com exchanges e queues iguais às do RabbitMQ 0-9-1; produtos mapeiam conceitos do protocolo para suas próprias entidades.

Arquitetos precisam registrar versão e implementação explicitamente. Dizer apenas usamos AMQP é insuficiente. Uma biblioteca AMQP 1.0 não se conecta automaticamente a um endpoint que aceita apenas 0-9-1. Também variam autenticação SASL, endereçamento, settlement , transactions e extensões do produto.

radio_button_unchecked 31.12 Jakarta Messaging/JMS

JMS foi a API Java padronizada para mensageria corporativa e hoje faz parte de Jakarta Messaging. Ela oferece interfaces para criar conexões, produzir, consumir e ler mensagens por meio de um provider. A API simplificada usa JMSContext , enquanto o modelo clássico separa Connection, Session , MessageProducer e MessageConsumer. Destination representa Queue ou Topic.

JMS define modelos point-to-point e publish/subscribe, durable subscriptions, selectors, delivery mode, priority, expiration, acknowledgement modes e sessões transacionadas. Também integra-se a transações distribuídas por XA quando o provider e o ambiente suportam. XA pode ser necessário em legados, porém adiciona acoplamento e custo operacional; padrões como Outbox são frequentemente preferidos em microserviços.

JMS não define um único protocolo de rede nem garante que todos os providers implementem topologias idênticas. Um provider pode usar protocolo proprietário, AMQP ou outro transporte. Migrar de provider exige validar semântica de destino, redelivery, selectors, transações, temporary destinations, durable subscriptions e administração. O código Java pode compilar e ainda apresentar comportamento operacional diferente.

try (JMSContext context = connectionFactory.createContext()) {
    Queue fila = context.createQueue("fila.pagamentos");
    JMSProducer producer = context.createProducer();
    producer.setProperty("eventType", "PagamentoCriado");
    producer.send(fila, jsonPayload);
}
// O consumidor deve tratar redelivery e idempotência.

radio_button_unchecked 31.13 Padrões de integração com mensageria

Competing Consumers distribui trabalho entre instâncias. Publish/Subscribe entrega o mesmo evento a grupos diferentes. Request -Reply usa correlation ID e reply destination, mas pode recriar acoplamento síncrono sobre o broker . Dead Letter Channel isola mensagens não processáveis. Retry com atraso deve diferenciar falha transitória de erro permanente e limitar tentativas.

Transactional Outbox grava alteração de negócio e evento na mesma transação local; um relay publica depois. Inbox registra mensagens processadas para deduplicação. Saga coordena transações locais e compensações. Event-Carried State Transfer leva dados suficientes no evento para reduzir chamadas síncronas. Claim Check armazena payload grande fora do broker e transporta apenas referência segura.

Cada padrão tem custo. Retry queues aumentam topologia e latência. DLQ sem processo operacional vira cemitério silencioso. Request -Reply pode saturar filas temporárias. Event-Carried State Transfer replica dados e exige governança de privacidade. O desenho deve incluir SLO , monitoramento, ownership e procedimento de reprocessamento.

radio_button_unchecked 31.14 Segurança, governança de schemas e privacidade

Segurança começa no transporte e identidade. Kafka pode usar TLS , mTLS , SASL e ACLs; RabbitMQ combina TLS , mecanismos de autenticação, usuários, vhosts e permissões; providers JMS possuem controles próprios. Credenciais precisam de rotação, menor privilégio e separação por aplicação. Confiar em rede interna não substitui autenticação entre workloads.

Autorização deve limitar tópicos, grupos, exchanges, filas e operações administrativas. Um produtor comprometido não deve publicar em qualquer domínio, e um consumidor não deve ler eventos sensíveis sem necessidade. Em brokers multi-tenant, quotas, isolamento de namespace e proteção contra noisy neighbor são parte da segurança.

Schemas precisam de catálogo, owner, compatibilidade e classificação de dados. Eventos persistidos por dias ou meses ampliam impacto de vazamento e direito de retenção. Criptografia em repouso protege mídia, mas não impede consumidores autorizados de ver payload . Tokenização, minimização e separação de tópicos podem ser necessárias para LGPD e políticas corporativas.

radio_button_unchecked 31.15 Alta disponibilidade, capacidade e backpressure

Kafka distribui partições e réplicas entre brokers. RabbitMQ usa quorum queues, streams e outros mecanismos conforme o tipo de dado. Alta disponibilidade não é apenas ter três nós: é necessário distribuir falhas, testar eleição de líderes, verificar replicação, dimensionar disco e garantir que clientes descubram novos líderes ou reconectem corretamente.

Capacidade é determinada por taxa de entrada, taxa de saída, tamanho de mensagem, retenção, replicação e backlog máximo. Um fluxo que recebe 20 MB/s, replica três vezes e retém sete dias exige muito mais que a soma do payload de negócio. Compactação, índices, page cache , picos, rebalance e margem operacional entram no cálculo.

Backpressure evita que produtores ou brokers sobrecarreguem consumidores. Kafka expressa pressão por lag, limites de polling e capacidade do consumidor. RabbitMQ usa prefetch , flow control e limites de fila. A aplicação precisa reduzir consumo, escalar ou rejeitar trabalho conscientemente. Acumular backlog sem SLO apenas desloca a indisponibilidade para o futuro.

Planejamento de capacidade

Dimensione para o pior backlog aceitável, não apenas para a média. Inclua retenção, replicação, overhead, reprocessamento, manutenção e crescimento. O broker precisa sobreviver ao período em que consumidores estão degradados.

radio_button_unchecked 31.16 Observabilidade e troubleshooting

Observabilidade de mensageria precisa conectar produtor, broker e consumidor. Métricas essenciais incluem taxa de publicação, taxa de consumo, bytes, latência, erros, confirms pendentes, mensagens não confirmadas, lag, backlog, idade da mensagem mais antiga, redeliveries, DLQ, partições sem réplica sincronizada e utilização de disco. Uma métrica isolada raramente explica o problema.

Em Kafka, lag alto pode significar consumidor lento, partição quente, rebalance frequente, erro de processamento ou falta de capacidade. Em RabbitMQ, ready messages, unacked messages e taxa de acknowledgements ajudam a distinguir fila acumulada de consumidores travados. Em JMS, o diagnóstico também depende do provider e do modo de acknowledgement ou transação.

Traces distribuídos devem propagar traceparent ou contexto equivalente em headers , mas o span assíncrono não deve fingir ser uma chamada síncrona longa. Correlation IDs, message IDs, causation IDs e timestamps permitem reconstruir cadeia de eventos. Logs precisam evitar payloads sensíveis e registrar decisões: published, confirmed, delivered, retried, dead-lettered e acknowledged.

radio_button_unchecked 31.17 Estudos de caso e laboratórios

Estudo de caso 1 - pagamentos: a API registra a ordem e uma Outbox na mesma transação. Um relay publica PagamentoCriado em Kafka usando pagamentoId como chave. Serviços de fraude, notificação e conciliação usam grupos independentes. O serviço de fraude mantém ordering por pagamento e publica a decisão. Replays são executados em tópicos de saída isolados para não reenviar efeitos externos.

Estudo de caso 2 - tarefas operacionais: um sistema publica comandos em uma exchange topic do RabbitMQ. Filas por capacidade recebem mensagens por routing key. Consumidores usam prefetch limitado, manual ack e retry com atraso. Depois do limite, mensagens seguem para DLQ com causa e contagem. Um processo operacional permite corrigir dado e republicar com idempotency key.

Estudo de caso 3 - legado Java: uma aplicação Jakarta EE usa JMS para publicar em um provider corporativo. A modernização preserva o contrato lógico, mas revisa transações XA, selectors, durable subscriptions e redelivery antes de migrar para outro broker . O time evita assumir que a mesma API Java significa comportamento idêntico entre providers.

Laboratórios sugeridos

1) Publique mensagens em Kafka com duas chaves e observe partições e offsets. 2) Crie dois consumers no mesmo grupo e depois em grupos diferentes. 3) No RabbitMQ, configure direct, topic e fanout exchanges. 4) Teste manual ack , prefetch , nack, requeue e DLQ. 5) Implemente um consumidor idempotente com Inbox. 6) Compare uma API JMS com o protocolo real usado pelo provider.

radio_button_unchecked Resumo do capítulo

Mensageria desacopla produtores e consumidores no tempo e na capacidade, mas não elimina contrato, ownership nem falhas distribuídas. Filas, publish/subscribe e logs particionados possuem ciclos de vida diferentes. A escolha deve considerar retenção, replay , ordering, fan-out e natureza do trabalho.

Kafka organiza tópicos em partições persistentes e oferece consumer groups, offsets, retenção, compactação e pipelines transacionais dentro de fronteiras controladas. RabbitMQ enfatiza roteamento por exchanges, filas, acknowledgements, confirms, quorum queues, streams e topologias de entrega flexíveis. AMQP 0-9-1 e AMQP 1.0 são protocolos distintos, apesar do nome comum.

Jakarta Messaging/JMS padroniza a programação Java, não o broker nem o protocolo de wire. Em qualquer plataforma, confiabilidade real depende da combinação de confirmações, idempotência , ordering, retries , DLQ, observabilidade e capacidade. O melhor desenho explicita as janelas de falha e o procedimento de recuperação.

Próximo passo do curso

O próximo capítulo aprofunda observabilidade de APIs e sistemas distribuídos, conectando logs , métricas e tracing com OpenTelemetry. Os conceitos de correlation ID, lag, backlog, redelivery e causalidade estudados aqui serão essenciais.

radio_button_unchecked Checklist de arquitetura e operação

• O modelo foi escolhido conscientemente: fila, pub/sub, log ou stream .
• Contrato, owner, versão e classificação de dados da mensagem estão documentados.
• Confirmação do produtor e acknowledgement do consumidor foram tratados separadamente.
• A unidade de ordering e a chave de particionamento estão definidas.
• Consumidores são idempotentes ou possuem estratégia explícita para duplicatas.
• Retries possuem limite, atraso e distinção entre falha transitória e permanente.
• DLQ possui alerta, owner, procedimento de análise e reprocessamento seguro.
• Retenção, replay e compactação foram avaliados contra privacidade e capacidade.
• Permissões seguem menor privilégio para tópicos, grupos, vhosts, exchanges e filas.
• Lag, backlog, idade da mensagem, confirms, unacked e DLQ são monitorados.
• Failover , eleição, reconexão e desastre foram testados.
• Planos de capacidade incluem replicação, picos, manutenção e reprocessamento.

radio_button_unchecked Exercícios

• Diferencie fila tradicional, publish/subscribe e log distribuído.
• Explique por que publisher confirm não substitui consumer acknowledgement .
• Descreva uma situação at-least-once e como torná-la idempotente.
• Explique por que Kafka preserva ordem por partição e não globalmente.
• Descreva a relação entre tópico, partição, offset e consumer group .
• Compare direct, topic, fanout e headers exchanges no RabbitMQ.
• Diferencie quorum queue , classic queue e stream .
• Explique por que AMQP 0-9-1 e AMQP 1.0 não devem ser tratados como a mesma coisa.
• Descreva o papel de JMSContext , Destination, Producer e Consumer.
• Projete retry e DLQ para um consumidor que chama um serviço externo.
• Liste métricas para diagnosticar lag alto no Kafka e unacked alto no RabbitMQ.
• Proponha uma estratégia de replay que não repita efeitos externos perigosos.

radio_button_unchecked Glossário

radio_button_unchecked Referências técnicas

• Apache Software Foundation. Apache Kafka Documentation - conceitos, design, operações, Connect e Streams .
• RabbitMQ Documentation - queues, exchanges, consumers, publisher confirms, quorum queues, streams , TTL e dead lettering.
• OASIS. Advanced Message Queuing Protocol (AMQP) Version 1.0.
• Jakarta EE. Jakarta Messaging 3.1 Specification and API Documentation.
• Enterprise Integration Patterns - Message Channel, Competing Consumers, Publish-Subscribe, Dead Letter Channel e Request -Reply.
• CloudEvents Specification - envelope padronizado para eventos.
• OpenTelemetry Specification - propagação de contexto em mensageria.
• OWASP e recomendações corporativas de segurança para brokers, credenciais e dados persistidos.

Nota de atualização

Versões de Kafka, RabbitMQ, bibliotecas e providers JMS evoluem. Antes de adotar configurações, valide a documentação oficial da versão implantada, especialmente para KRaft , consumer groups, quorum queues, streams , AMQP 1.0 e integração transacional.