Integração e API
Message Broker
Quando sensores, serviços e automações não podem depender de uma conexão direta, o message broker atua como intermediário persistente entre produtores e consumidores. RabbitMQ, Apache Kafka, NATS e Mosquitto implementam modelos distintos, como AMQP 0-9-1, MQTT 5.0 e logs particionados. Em comparação com chamadas REST síncronas, o broker desacopla disponibilidade e ritmo. A limitação é operacional: filas, retenção, confirmações, duplicatas e ordem exigem configuração, monitoramento e armazenamento.
🔀 Tipos de Comunicação
QUEUE
Filas ponto a ponto
No modelo de fila, um produtor publica uma mensagem e um consumidor do grupo a processa. RabbitMQ usa filas nomeadas, acknowledgements e mecanismos de redelivery para distribuir tarefas entre workers. Em automação residencial, uma fila pode transportar comandos de geração de relatórios, processamento de imagens ou sincronização de histórico sem bloquear a API que recebeu o pedido. A fila absorve picos: dez mil eventos podem ser armazenados e consumidos na velocidade suportada pelo serviço. A semântica precisa ser declarada. Entrega pelo menos uma vez pode gerar duplicatas; entrega no máximo uma vez pode perder mensagens; “exatamente uma vez” costuma depender de idempotência e transações além do broker. O tempo de retenção, o tamanho máximo e a política de overflow também precisam ser definidos. Uma fila não é banco de dados permanente. Ela serve para transferência controlada de trabalho.
PUB/SUB
Publish/subscribe por tópicos
No padrão publish/subscribe, produtores publicam em um assunto e múltiplos assinantes recebem cópias. MQTT usa tópicos hierárquicos como `casa/sala/temperatura`; RabbitMQ oferece exchanges fanout, direct, topic e headers; NATS organiza subjects. O modelo permite que Home Assistant, um gravador histórico e um serviço de alertas consumam o mesmo evento sem o sensor conhecer cada destino. O desacoplamento melhora expansão. Também amplia a necessidade de governança. Tópicos precisam de convenção, versão e controle de acesso. Wildcards muito amplos podem expor dados de presença ou gerar carga. Retained messages e sessões persistentes alteram a experiência. O consumidor deve distinguir evento novo de estado retido. A topologia precisa evitar loops quando duas plataformas republicam o mesmo estado.
STREAM
Streams e logs persistentes
Brokers de streaming, como Apache Kafka, tratam mensagens como registros ordenados em partições. Consumidores mantêm offsets e podem reler dados. RabbitMQ Streams e JetStream no NATS aproximam esse modelo. É útil para telemetria de energia, temperatura, eventos de dispositivos e auditoria quando a reprodução histórica faz parte do requisito. A ordem é normalmente garantida apenas dentro de uma partição, não no sistema inteiro. Chaves de particionamento determinam afinidade. Retenção pode ser por tempo, como 7 dias, ou por tamanho. Compactação mantém o último valor por chave em implementações que oferecem o recurso. A solução custa mais armazenamento e operação que uma fila simples. Em uma residência, Kafka raramente se justifica; em um condomínio ou plataforma de milhares de dispositivos, o replay pode ser decisivo.
AMQP/MQTT
Protocolos e adaptadores de mensageria
Um message broker pode aceitar vários protocolos. RabbitMQ documenta suporte a AMQP 0-9-1, AMQP 1.0, MQTT 5.0 e STOMP por componentes adequados. Mosquitto concentra MQTT. Brokers gerenciados de nuvem podem expor MQTT sobre TLS na porta 8883, WebSockets para navegadores e APIs administrativas. A interoperabilidade não significa equivalência. MQTT QoS 1 não se traduz automaticamente em todas as garantias de uma fila AMQP. Cabeçalhos, prioridades, transações, tamanho de mensagem e roteamento variam. Bridges podem conectar brokers, mas introduzem atraso, duplicação e risco de ciclo. O projeto escolhe um contrato canônico e trata adaptações explicitamente, em vez de presumir que qualquer cliente pode consumir qualquer recurso.
✅ Vantagens Arquiteturais
⚡
Desacoplamento temporal entre produtores e consumidores
O produtor pode concluir a publicação mesmo quando o consumidor está temporariamente indisponível, desde que o broker aceite e persista a mensagem conforme a política. Isso é diferente de uma chamada REST síncrona, na qual o serviço solicitante aguarda resposta e herda a indisponibilidade do destino. Em casa inteligente, um gateway pode registrar eventos durante a reinicialização do sistema analítico e entregá-los depois. O benefício depende da durabilidade real: fila durável, mensagem persistente, confirmação do publisher e armazenamento saudável. Publicar num socket não garante gravação. O produtor deve receber confirmação do broker. O consumidor confirma somente depois de concluir a ação necessária. Se confirmar antes, uma falha perde o trabalho. Se confirmar depois, pode reprocessar. A aplicação precisa ser idempotente.
⚡
Absorção de picos e controle de pressão
Filas funcionam como buffer entre taxas diferentes. Um surto de 5.000 eventos após retorno de energia pode ser processado por dez workers sem sobrecarregar banco e APIs. Prefetch, créditos, quotas e limites de concorrência controlam a pressão. Sem esses mecanismos, consumidores lentos acumulam memória ou conexões. O broker também precisa de limites. Uma fila sem máximo pode encher disco. Políticas de TTL, dead-lettering e overflow precisam ser escolhidas. Em automação, eventos de presença antigos podem perder valor após 30 s, enquanto comandos de faturamento exigem retenção. O custo-benefício aparece quando cada classe de mensagem recebe política própria. Tratar tudo como durável e infinito encarece e pode degradar a operação.
⚡
Roteamento centralizado com menos integrações ponto a ponto
Sem broker, dez produtores e dez consumidores podem gerar até cem integrações diretas. Com uma camada de mensageria, cada componente publica e assina contratos conhecidos. Exchanges, tópicos e filtros encaminham. Isso reduz dependências de endereço e autenticação entre cada par. A centralização cria um componente crítico. Cluster, quorum queues, replicação e observabilidade podem ser necessários. Em uma casa, um broker Mosquitto único em mini PC pode ser suficiente e simples de restaurar. Em serviço comercial, o mesmo desenho seria frágil. A arquitetura deve corresponder ao impacto da indisponibilidade. O broker não deve concentrar lógica de negócio excessiva em regras de roteamento difíceis de versionar.
⚡
Observabilidade e controle operacional
Brokers expõem métricas de profundidade de fila, taxa de publicação, taxa de consumo, mensagens não confirmadas, conexões, uso de disco e memória. Esses indicadores revelam gargalos antes da falha. Uma fila crescendo continuamente indica consumidor lento, erro ou aumento de carga. A idade da mensagem mais antiga é frequentemente mais informativa que a contagem. Logs e tracing permitem correlacionar. IDs de mensagem, correlation IDs e headers ajudam. O monitoramento precisa evitar registrar payloads sensíveis. Em automação residencial, presença, fechaduras e câmeras produzem dados pessoais. Dashboards devem mostrar saúde sem expor conteúdo. Alertas precisam ter limiares e janela, não disparar por cada pico transitório.
⚡
Integração entre tecnologias e ritmos diferentes
O broker pode conectar dispositivos MQTT de 2,4 GHz, serviços HTTP, workers Python, bancos e plataformas de automação. Um adaptador transforma um evento Zigbee em mensagem MQTT; outro grava em TimescaleDB; outro envia notificação. Cada componente evolui separadamente. A vantagem é portabilidade. A limitação é o contrato. Payload JSON sem schema tende a divergir: `temperature`, `temp` e `value` passam a coexistir. JSON Schema, Protocol Buffers ou Avro podem definir. Versionamento precisa ser explícito. Consumidores devem tolerar campos novos. O broker transporta bytes; não garante significado. A interoperabilidade real depende de governança semântica.