As arquiteturas de mensagens portáteis separam a camada de transporte da lógica de negócio, permitindo que as mensagens circulem entre redes, protocolos e plataformas sem reescrever o código da aplicação. Três famílias cobrem quase todos os cenários em produção: orientada a conexão, orientada a filas e híbrida, com latências p50 típicas de 50 a 300 ms.
Pontos principais
- Três tipos de arquitetura cobrem o campo: conexão, filas e híbrida.
- A latência orienta a escolha. O p50 varia entre 50 e 300 ms.
- A escolha do broker importa. RabbitMQ, Kafka e NATS resolvem problemas distintos de encaminhamento e taxa de transferência.
- Os frameworks criam portabilidade. Adaptadores agnósticos ao transporte permitem trocar de protocolo sem mexer no código.
- Gerido ou autogerido é uma decisão real: gerir por conta própria exige limites de taxa, contrapressão e autenticação rigorosos.
1. O que "portátil" significa mesmo
O termo técnico é mensageria agnóstica ao transporte. A portabilidade vem de núcleos de mensagem abstratos e de invólucros de envelope que preservam a identidade do payload seja qual for o protocolo. As arquiteturas de conexão minimizam a latência, as de filas maximizam taxa e durabilidade, e as híbridas cedem um pouco de cada em troca de flexibilidade.
WebSocket (RFC 6455), MQTT (ISO/IEC 20922) e AMQP 1.0 são os transportes mais implantados. Escolher uma arquitetura sem saber que protocolos suporta prende a equipa a um único caminho de entrega, o oposto de portabilidade.
2. Arquitetura orientada a conexão
As mensagens seguem por conexões persistentes geridas pelo servidor até um gateway central. O WebSocket domina; em service meshes os fluxos gRPC cumprem o mesmo papel.
- Latência p50 de 50–100 ms: a opção mais rápida para mensagens voltadas ao utilizador.
- Entrega síncrona, com retorno imediato do estado.
- A presença permite confirmações de leitura e indicadores de escrita, mas consome recursos.
- O tamanho dos grupos é limitado: o fan-out consome memória proporcional ao número de destinatários.
Serve para chat de suporte em tempo real, OTP por push e consolas de agente, onde se espera resposta abaixo de 200 ms.
A prever: se um nó de gateway cai, todas as sessões nele caem juntas. Escalar horizontalmente exige sessões persistentes ou uma camada de presença partilhada.
Dica prática. Execute a presença como serviço dedicado, separado do encaminhamento, para que uma tempestade de reconexões não bloqueie a taxa de entrega.
3. Arquitetura orientada a filas
Um broker armazena, ordena e entrega as mensagens de forma assíncrona. O remetente publica numa fila ou tópico.
- Garantias de entrega pelo menos uma vez protegem contra perdas durante paragens do consumidor.
- O replay permite reprocessar o histórico para análise, auditoria e investigação de incidentes.
- A contrapressão evita que produtores rápidos afoguem consumidores lentos.
- Taxa de transferência: clusters Kafka processam rotineiramente milhões de mensagens por segundo.
O p50 fica em 100–300 ms: adequado a lotes, análise, campanhas e integrações de workflow, lento demais para OTP em tempo real ou chat ao vivo.
| Broker | Melhor uso | Perfil de latência |
|---|---|---|
| RabbitMQ | Encaminhamento complexo, filas de tarefas | Moderado |
| Kafka | Fluxos de eventos de alto volume | Moderado a alto |
| NATS | RPC leve, baixa carga operacional | Baixo a moderado |
Dica prática. Escolha o broker pelo modelo de encaminhamento, não apenas pela taxa. Os exchanges do RabbitMQ resolvem problemas para os quais o modelo de partições do Kafka nunca foi desenhado.
4. Arquitetura híbrida
A híbrida combina envio direto nos caminhos sensíveis à latência com recolha via broker nos fluxos volumosos ou duráveis, cobrindo toda a faixa de 50 a 300 ms. Um banco envia OTP por socket direto enquanto marketing e tickets seguem pela fila.
- Auditabilidade: registo imutável do tráfego que não é em tempo real.
- Sincronização multi-dispositivo: a fila alcança cada dispositivo registado.
- Flexibilidade de protocolo: alternar entre MQTT, gRPC e WebRTC sem mudar a API.
- Suporte offline: as mensagens aguardam com TTL configurável.
A comunicação sem broker cria lacunas de observabilidade, pois não há registo para consultar. Um gateway de sockets com uma espinha dorsal pub/sub persistente devolve fiabilidade e trilho de auditoria.
| Característica | Conexão | Filas | Híbrida |
|---|---|---|---|
| Latência p50 | 50–100 ms | 100–300 ms | 50–300 ms |
| Durabilidade | Baixa | Alta | Alta |
| Suporte offline | Não | Sim | Sim |
| Registo de auditoria | Não | Sim | Sim |
| Presença em tempo real | Sim | Não | Sim |
5. Como os frameworks portáteis dão agilidade
Interfaces abstratas separam transporte e lógica: uma alteração de construtor troca WebSocket por MQTT ou gRPC mantendo a API em Python, Go, Node.js e .NET.
- Envelopes que separam identidade, metadados de encaminhamento e payload.
- Adaptadores de transporte com uma interface comum.
- Suporte multilíngua para partilhar esquemas de mensagem.
- Serialização integrada (Protocol Buffers, MessagePack, JSON) válida em todos os transportes.
Na comunicação local entre agentes, buffers circulares em ficheiro ou caixas de correio embebidas dão segurança contra falhas sem broker de rede, o que importa em cenários edge e embebidos.
O princípio é a independência da pilha de mensagens: nenhum transporte deve ficar fixado na lógica da aplicação.
Dica prática. Instrumente a camada de adaptadores, não apenas a aplicação. IDs de rastreio ao nível do envelope permitem reconstruir percursos após trocar de transporte.
6. Como escolher
Quatro critérios decidem: tolerância à latência, volume, complexidade do workflow e tolerância a falhas. Os erros típicos são usar conexão para lotes massivos (esgotamento de memória) ou filas para OTP em tempo real (atrasos inaceitáveis).
- Conexão: p50 abaixo de 100 ms, grupos limitados, presença necessária.
- Filas: o volume ultrapassa o fan-out de um gateway, contam durabilidade e replay, workflows em várias etapas.
- Híbrida: tempo real nos caminhos críticos e durabilidade no resto, ou conformidade que exige registo de auditoria.
| Critério | Conexão | Filas | Híbrida |
|---|---|---|---|
| Requisito de latência | Abaixo de 100 ms | 100–300 ms aceitável | Misto |
| Volume de mensagens | Moderado | Muito alto | Alto |
| Durabilidade necessária | Não | Sim | Sim |
| Complexidade operacional | Média | Alta | Alta |
Poucas empresas dependem de um só tipo. NATS para RPC, Kafka para fluxos de eventos e RabbitMQ para filas de tarefas é uma combinação cada vez mais comum: a ferramenta certa para cada camada.
Onde entra a camada de entrega
A arquitetura é metade do problema; operá-la de forma fiável entre fornecedores e canais é a outra metade. A Flowstates opera um gateway de mensagens gerido com os controlos operacionais que a sua arquitetura pressupõe: limites de taxa, contrapressão, autenticação e encaminhamento multi-fornecedor em SMS, RCS, WhatsApp, OTP, email e voz, com escalonamento em falhas de entrega de OTP.
Perguntas frequentes
Quais são os três tipos principais? Conexão, filas e híbrida, com p50 de 50–100 ms, 100–300 ms e 50–300 ms.
Quando usar filas? Quando durabilidade, replay e taxa de transferência importam mais do que a entrega em tempo real.
O que torna uma arquitetura portátil? Separar transporte e lógica de negócio através de envelopes e adaptadores abstratos.
Qual o principal risco sem broker? Lacunas de observabilidade, porque não há registo para auditar.
Como as empresas combinam os tipos? Normalmente NATS para RPC leve, Kafka para fluxos de eventos e RabbitMQ para filas de tarefas complexas, em paralelo.
Começar pequeno e depois expandir
A escolha de arquitetura não é uma decisão única. As equipas escolhem sockets pela velocidade, constroem tudo por cima e, dezoito meses depois, descobrem que os fluxos de marketing competem com a entrega de OTP pelos mesmos recursos de gateway, degradando ambos. Uma híbrida leve desde o início custa menos do que acrescentar um broker mais tarde.
Se quiser uma camada de entrega gerida sob a sua arquitetura, marque uma revisão de mensagens de 30 minutos.