Integração e API
Event Bus
Event Bus é uma infraestrutura de distribuição que recebe eventos e os entrega a assinantes sem exigir chamada direta entre produtor e consumidor. O conceito apareceu em sistemas orientados a eventos muito antes das plataformas IoT atuais; em Home Assistant, o event bus interno carrega mudanças de estado e eventos, enquanto Kafka ou NATS atendem sistemas distribuídos. A ressalva é que “bus” não define durabilidade, ordenação nem entrega: essas garantias dependem da implementação, e eventos excessivos podem criar loops e acoplamento oculto.
🔀 Tipos de Comunicação
In-process
Barramento em memória dentro da aplicação
Um dispatcher mantém listas de handlers e chama assinantes quando um evento ocorre. Frameworks de UI, servidores e Home Assistant usam padrões semelhantes. A latência é baixa e não exige rede. Eventos podem ser objetos ricos. O custo é acoplamento ao processo: se o programa reinicia, eventos não persistidos somem; um handler lento pode bloquear os demais; falhas podem propagar. A ordem costuma ser a ordem de registro ou scheduling, mas não deve ser presumida sem contrato. Em Home Assistant, o event bus é central para state_changed, call_service e eventos de integrações. Escutar tudo gera volume. Handlers precisam filtrar por tipo e não realizar I/O bloqueante no loop. Para durabilidade, o recorder é outra camada, não o bus em si.
Distributed
Barramento distribuído por broker ou log
Kafka, NATS, Pulsar, RabbitMQ, MQTT e serviços cloud podem cumprir o papel de event bus entre processos. Cada produto possui semântica diferente. Kafka mantém log particionado e permite replay; NATS Core prioriza baixa latência e JetStream acrescenta persistência; RabbitMQ roteia filas; MQTT usa tópicos e QoS. Chamar todos de bus não os torna intercambiáveis. O projeto precisa escolher garantias. Eventos de telemetria podem tolerar perda; comandos de fechadura, não. O barramento distribuído exige autenticação, TLS, ACL, observabilidade, capacidade e operação. A latência inclui rede e broker. Um cluster aumenta disponibilidade, mas também custo.
Event Model
Tópicos, tipos e envelopes de eventos
Eventos precisam de nome estável, versão, ID, origem, timestamp, subject e payload. CloudEvents oferece um formato padronizado para atributos como id, source, type, specversion e time. Um evento casa.sensor.temperature.changed deve declarar unidade e qualidade. O envelope permite deduplicação e roteamento. O payload é validado por JSON Schema, protobuf ou Avro. O nome deve representar fato no passado, não comando disfarçado. TemperatureChanged afirma algo ocorrido; SetTemperature é intenção. Misturar leva consumidores a executar ações inesperadas. O ID precisa ser único. Timestamp da observação é diferente do processamento. A versão deve permitir evolução.
Subscription
Assinatura, filtros e roteamento
Consumidores registram interesse por tipo, tópico, subject, chave ou expressão. Filtros no broker reduzem tráfego; filtros no consumidor são mais flexíveis, mas recebem tudo. Wildcards precisam de governança. Assinar casa/# é conveniente e arriscado. Em barramentos internos, um listener global pode causar alto CPU. A entrega pode ser fan-out — todos recebem — ou consumer group — uma instância processa. O contrato precisa distinguir. Em automação, duas regras assinadas ao mesmo evento podem ambas comandar o dispositivo. Isso é esperado, mas conflitos precisam de prioridade ou estado desejado. O bus não arbitra automaticamente.
Durability
Replay, persistência e retenção
Alguns buses mantêm eventos por horas, dias ou indefinidamente; outros não. Replay permite reconstruir estado ou reprocessar. Retenção aumenta armazenamento e risco de privacidade. Eventos de presença revelam rotina. A política deve ser por tipo. Um event bus em memória não oferece replay. Kafka usa offsets; JetStream usa consumidores e acknowledgments; serviços cloud usam retenção. Reprocessar comandos pode ser perigoso; prefira eventos idempotentes e consumidores com checkpoints. O estado atual não deve ser obtido obrigatoriamente reproduzindo anos de eventos, a menos que a arquitetura seja event sourcing. Event bus e event store são conceitos distintos.
✅ Vantagens Arquiteturais
⚡
Reduz dependências diretas entre integrações
O sensor publica um fato sem conhecer iluminação, climatização ou histórico. Novos consumidores são adicionados sem alterar o produtor. Isso acelera evolução. O desacoplamento é temporal apenas se o bus é durável; em memória, produtor e processo ainda precisam estar ativos. Também pode surgir acoplamento implícito ao nome e payload do evento. Sem catálogo, ninguém sabe quem consome. Mudanças quebram silenciosamente. A solução é schema registry, documentação AsyncAPI, owner e observabilidade. Desacoplamento técnico não elimina governança.
⚡
Permite múltiplas reações ao mesmo fato
Um evento de vazamento pode fechar válvula, enviar notificação, ligar sirene e registrar incidente. Cada consumidor tem responsabilidade. Falha de notificação não precisa impedir fechamento. Em execução síncrona no mesmo processo, porém, um handler pode afetar o loop. Use tarefas e limites. Em distribuído, consumidores independentes isolam melhor. A ordem entre reações não é garantida. Se a sirene só deve tocar depois da válvula confirmar, modele evento ValveClosed ou orquestração, não dependa da ordem de assinatura. O bus distribui; não coordena transações.
⚡
Facilita observabilidade e auditoria quando os eventos são estruturados
Um ponto central pode medir taxa, latência, erros e consumidores. IDs de correlação ligam gatilho e ações. Em casa inteligente, um trace pode mostrar movimento → ocupação → luz. O bus precisa preservar metadata. Logs não devem guardar payload sensível indiscriminadamente. A observabilidade pode usar métricas por tipo e amostragem. Um evento de alta frequência, como potência a cada segundo, gera milhões de registros. Agregação é necessária. O monitoramento precisa distinguir backlog de taxa normal. Um bus invisível cria automações “misteriosas”; um catálogo e trace reduzem MTTR.
⚡
Suporta expansão de plataformas e integração de domínios
Iluminação, energia, segurança e HVAC podem compartilhar fatos comuns sem APIs ponto a ponto. Um gateway traduz Zigbee para eventos, um serviço de energia consome, e o controlador mantém. Essa arquitetura escala melhor que N×M integrações. O custo é infraestrutura. Para uma casa com 20 dispositivos, um broker adicional pode ser desnecessário. O event bus interno da plataforma pode bastar. Para condomínio, múltiplos serviços e histórico, um bus distribuído se justifica. O critério é número de produtores, consumidores, volume, isolamento e necessidade de replay.
⚡
Promove modelos reativos em vez de polling
Consumidores recebem mudanças quando ocorrem e evitam consultar APIs a cada segundo. Isso reduz carga e latência. O produtor precisa emitir eventos confiáveis. Se um evento se perde, o consumidor pode ficar inconsistente. Snapshots, retained states ou reconciliação periódica complementam. A arquitetura reativa não elimina consulta; usa-a para recuperação. Em sensores a bateria, eventos são naturais. Em APIs antigas sem eventos, um adaptador faz polling e publica. O intervalo e a carga permanecem. O bus não cria capacidade que a origem não tem.