Usar MQTT para SaaS IoT permite entregar dados de dispositivos em tempo real a muitos clientes a partir de um único produto, mas só se você separar esses clientes corretamente desde o primeiro dispositivo. Este guia mostra como escolher um modelo de isolamento, projetar credenciais e prefixos de topic, integrar dispositivos e estruturar o seu back-end sobre um broker MQTT gerenciado, para lançar mais rápido e escalar sem rearquitetar.
O Formato de uma Plataforma SaaS IoT
A maioria dos produtos SaaS IoT segue o mesmo padrão. Dispositivos em campo publicam telemetria e status. Um back-end assina, armazena dados, avalia lógica e serve uma API. Um app web ou mobile mostra a cada cliente apenas os seus próprios dispositivos e envia comandos de volta. O MQTT fica no meio porque lida bem com conectividade intermitente, payloads pequenos e mensagens bidirecionais. Se o protocolo é novo para você, comece por o que um broker MQTT faz.
O broker é infraestrutura compartilhada do seu negócio, mas os dados nele pertencem aos seus clientes. Disso decorrem três decisões de design:
- Com que rigor os clientes são separados no broker?
- Como os dispositivos são identificados e autenticados?
- Como os topics são estruturados para que o seu back-end roteie os dados por cliente?
Decisão 1: Escolha um Modelo de Isolamento de Clientes
Modelo A: Um Broker por Cliente
Cada cliente recebe o seu próprio broker, com credenciais de endpoint próprias e o seu próprio espaço de topics. Os dispositivos do cliente A fisicamente não conseguem assinar os topics do cliente B, porque não estão no mesmo namespace de broker. O seu back-end se conecta a cada broker de cliente como um cliente MQTT.
Isso oferece a separação mais forte e torna simples os limites por cliente, o desligamento de clientes e a exclusão de dados: basta excluir o broker. O custo é ter mais brokers para provisionar e um back-end que gerencia muitas conexões.
Modelo B: Um Broker Compartilhado com Prefixos de Topic
Os dispositivos de todos os clientes se conectam a um único broker, e os topics de cada cliente começam com um prefixo como acme/ ou um ID de cliente. O seu back-end assina +/devices/+/telemetry e deduz o cliente a partir do primeiro nível do topic.
Isso é simples e eficiente, mas um prefixo de topic por si só é uma convenção de organização, não uma fronteira de controle de acesso. Se qualquer dispositivo no broker puder assinar #, ele verá os dados de todos os clientes. Use esse modelo apenas quando você controla todo o firmware dos dispositivos e nada voltado ao cliente se conecta diretamente ao broker, ou quando o seu broker impõe restrições de topics por tenant.
Modelo C: Em Camadas
Clientes menores compartilham um broker, enquanto clientes grandes ou regulados recebem o seu próprio broker, um cluster dedicado ou uma implantação na própria conta de nuvem. Isso espelha a forma como muitas empresas SaaS precificam os seus planos.
| Modelo | Força da separação | Sobrecarga operacional | Melhor para |
|---|---|---|---|
| A: broker por cliente | Forte, imposta pelo broker | Moderada | Produtos B2B, acesso voltado ao cliente |
| B: broker compartilhado, prefixos | Depende da imposição | Baixa | Firmware totalmente controlado, apenas dados internos |
| C: em camadas | Forte onde importa | Moderada | Produtos com planos self-service e enterprise |
Os conceitos subjacentes são abordados em isolamento de tenants MQTT e na arquitetura de broker MQTT multi-tenant.
Decisão 2: Design de Credenciais
O seu modelo de credenciais determina com que segurança você consegue integrar, revogar e rotacionar dispositivos.
- Client IDs por dispositivo. Todo dispositivo precisa de um client ID único e estável. Derive-o de um número de série ou de um registro de provisionamento, nunca de um valor aleatório gerado na inicialização, ou as sessões persistentes não serão retomadas.
- Nada de credenciais em repositórios públicos ou pacotes de apps. Apps mobile e web não devem guardar credenciais de broker em nível de dispositivo. Faça-os chamar a sua API e deixe o back-end conversar com o broker, ou emita credenciais de curta duração e escopo restrito se o seu broker suportar.
- Caminho de revogação. Quando um cliente cancela ou um dispositivo é roubado, você precisa conseguir cortá-lo sem afetar os outros dispositivos.
- Caminho de rotação. Planeje como o firmware recebe novas credenciais, por exemplo por um topic de configuração autenticado ou durante uma atualização OTA.
Decisão 3: Design de Topics para Roteamento Multicliente
Uma árvore de topics previsível simplifica o back-end e mantém seguras as assinaturas com wildcard. Um padrão que funciona bem:
<customer>/<site>/<device-id>/telemetry
<customer>/<site>/<device-id>/status
<customer>/<site>/<device-id>/cmd
<customer>/<site>/<device-id>/cmd/response
Diretrizes:
- Coloque o cliente primeiro, para que um wildcard por nível dê uma visão completa do cliente.
- Mantenha os identificadores estáveis, em minúsculas e sem espaços.
- Use retained messages em
statuspara que os dashboards vejam imediatamente o último estado conhecido. - Use response topics e correlation data do MQTT 5 para fluxos de comando e resposta, em vez de inventar o seu próprio mecanismo.
- Evite dados pessoais nos nomes de topics; topics aparecem em logs e ferramentas.
No Modelo A, o nível do cliente fica implícito no broker, então você pode removê-lo do topic ou mantê-lo para consistência entre os planos.
Um Serviço Mínimo de Ingestão no Back-End
O back-end assina, valida e armazena. Este exemplo em Python, usando paho-mqtt 2.x e MQTT 5, ingere telemetria de um broker compartilhado e extrai o cliente do topic. No ConnectMQ Serverless (Paid), você pode escalar esses workers de ingestão horizontalmente com uma shared subscription como $share/ingest/+/+/+/telemetry, que distribui as mensagens entre os workers.
import json
import ssl
import paho.mqtt.client as mqtt
SUBSCRIPTION = "+/+/+/telemetry" # use $share/ingest/+/+/+/telemetry em planos com shared subscriptions
def store(customer, site, device, data):
# Substitua pela gravação no seu banco de dados
print(f"[{customer}] {site}/{device}: {data}")
def on_connect(client, userdata, flags, reason_code, properties):
print("Ingest connected:", reason_code)
client.subscribe(SUBSCRIPTION, qos=1)
def on_message(client, userdata, msg):
parts = msg.topic.split("/")
if len(parts) != 4:
return
customer, site, device, _ = parts
try:
data = json.loads(msg.payload)
except json.JSONDecodeError:
print("Rejected non-JSON payload on", msg.topic)
return
store(customer, site, device, data)
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="YOUR_CLIENT_ID",
protocol=mqtt.MQTTv5)
client.username_pw_set("YOUR_USERNAME", "YOUR_PASSWORD")
client.tls_set(cert_reqs=ssl.CERT_REQUIRED)
client.on_connect = on_connect
client.on_message = on_message
client.connect("YOUR_BROKER_HOST", 8883, keepalive=60)
client.loop_forever()
Integrações como bancos de dados, notificações ou analytics ficam penduradas nesse serviço, ou em ferramentas como Node-RED e Telegraf que se conectam ao broker como clientes MQTT comuns.
Construindo sobre o ConnectMQ
O ConnectMQ é um broker MQTT gerenciado que se encaixa em cada um desses modelos. Todo broker que você cria recebe credenciais geradas e um client ID vinculado a elas, e os brokers ficam isolados uns dos outros no cluster compartilhado. Isso torna o Modelo A direto: crie um broker por cliente, guarde as credenciais no seu back-end e conecte o seu serviço de ingestão a cada um deles.
Os limites dos planos se mapeiam naturalmente para os planos de um SaaS. O plano Serverless gratuito suporta até 25 conexões, QoS até 1 e mensagens de 256 KB, ideal para desenvolvimento e clientes piloto. O Serverless (Paid) suporta até 1.000 conexões, QoS 2, mensagens de 1 MB e shared subscriptions. O Dedicated dá a um cliente um cluster isolado, e o BYOC roda o broker em uma conta de nuvem controlada por você ou pelo seu cliente, gerenciado pelo ConnectMQ.
O portal também ajuda as equipes de suporte: o explorador de topics ao vivo e o cliente MQTT no navegador permitem ver o que os dispositivos de um cliente estão realmente enviando, a visão de dispositivos agrupa os equipamentos por níveis ISA-95 para clientes industriais, e as regras de alerta por limite com log de alertas sinalizam valores fora da faixa.
Checklist de Lançamento do Seu SaaS IoT
- Modelo de isolamento escolhido e documentado para cada plano de preço.
- Client ID e credenciais únicos por dispositivo, com procedimento de revogação.
- Árvore de topics documentada e validada no back-end.
- TLS apenas na porta 8883 (dispositivos) e 8084 (clientes de navegador).
- Reconexão com backoff exponencial e jitter em todo o firmware.
- Serviço de ingestão escalado com shared subscriptions onde houver suporte.
- Broker de staging separado para testes de firmware e back-end.
- Monitoramento e alertas de conexões e fluxo de mensagens por cliente; veja o checklist MQTT para produção.
Comece com o ConnectMQ
Crie o protótipo do seu SaaS em um broker Serverless gratuito em app.connectmq.com, sem cartão de crédito, e depois adicione um broker por cliente conforme fechar contratos. Você também pode testar ideias no servidor MQTT público (gratuito), pensado para testes e sem dados reais de clientes, antes de criar uma conta e ler o guia de broker MQTT na nuvem para comparar as opções de hospedagem.
Perguntas frequentes
Cada cliente do SaaS deve ter o seu próprio broker MQTT?
Se os clientes ou os apps deles se conectam diretamente, ou se os contratos exigem separação, sim. Um broker por cliente oferece isolamento imposto e um desligamento simples.
Prefixos de topic bastam para separar clientes?
Eles organizam os dados, mas só os protegem se o broker impuser quais prefixos cada cliente pode usar. Sem essa imposição, qualquer cliente que assine # veria tudo.
Como escalo o back-end que consome os dados dos dispositivos?
Rode vários workers de ingestão usando uma shared subscription do MQTT 5, para que o broker balanceie as mensagens entre eles.
Meu app mobile pode se conectar diretamente ao broker?
Pode, via Secure WebSocket na porta 8084, mas evite embutir credenciais de dispositivo no app. Passe pela sua API ou use credenciais com escopo restrito por usuário.
