MQTT para SaaS IoT sobre un broker MQTT gestionado

Usar MQTT para SaaS IoT te permite entregar datos de dispositivos en tiempo real a muchos clientes desde un único producto, pero solo si separas correctamente a esos clientes desde el primer dispositivo. Esta guía muestra cómo elegir un modelo de aislamiento, diseñar credenciales y prefijos de topic, dar de alta dispositivos y estructurar tu backend sobre un broker MQTT gestionado para lanzar antes y escalar sin rehacer la arquitectura.

La forma de una plataforma SaaS IoT

La mayoría de los productos SaaS IoT siguen el mismo patrón. Los dispositivos en campo publican telemetría y estado. Un backend se suscribe, almacena los datos, evalúa la lógica y sirve una API. Una aplicación web o móvil muestra a cada cliente solo sus propios dispositivos y envía comandos de vuelta. MQTT se sitúa en el medio porque gestiona bien la conectividad intermitente, los payloads pequeños y la mensajería bidireccional. Si el protocolo es nuevo para ti, empieza por qué hace un broker MQTT.

El broker es infraestructura compartida de tu negocio, pero los datos que circulan por él pertenecen a tus clientes. De ahí se derivan tres decisiones de diseño:

¿Con qué intensidad se separan los clientes en el broker?
¿Cómo se identifican y autentican los dispositivos?
¿Cómo se estructuran los topics para que tu backend pueda enrutar los datos por cliente?

Decisión 1: elige un modelo de aislamiento de clientes

Modelo A: un broker por cliente

Cada cliente obtiene su propio broker, con sus propias credenciales de endpoint y su propio espacio de topics. Los dispositivos del cliente A no pueden físicamente suscribirse a los topics del cliente B, porque no están en el mismo namespace de broker. Tu backend se conecta como cliente a cada broker de cliente.

Esto ofrece la separación más fuerte y simplifica los límites por cliente, las bajas y la eliminación de datos: borras el broker. El coste es tener más brokers que aprovisionar y un backend que gestiona muchas conexiones.

Modelo B: un broker compartido con prefijos de topic

Los dispositivos de todos los clientes se conectan a un broker, y los topics de cada cliente empiezan con un prefijo como acme/ o un ID de cliente. Tu backend se suscribe a +/devices/+/telemetry y deduce el cliente a partir del primer nivel del topic.

Es sencillo y eficiente, pero un prefijo de topic por sí solo es una convención organizativa, no una frontera de control de acceso. Si cualquier dispositivo del broker puede suscribirse a #, puede ver los datos de todos los clientes. Usa este modelo solo cuando controles todo el firmware de los dispositivos y nada orientado al cliente se conecte directamente al broker, o cuando tu broker aplique restricciones de topic por tenant.

Modelo C: por niveles

Los clientes pequeños comparten un broker, mientras que los grandes o regulados obtienen su propio broker, un clúster dedicado o un despliegue en su propia cuenta de nube. Esto refleja cómo muchas empresas SaaS estructuran sus planes de precios.

Modelo	Fuerza de la separación	Carga operativa	Ideal para
A: broker por cliente	Fuerte, aplicada por el broker	Moderada	Productos B2B, acceso de cara al cliente
B: broker compartido, prefijos	Depende de la aplicación forzosa	Baja	Firmware totalmente controlado, solo datos internos
C: por niveles	Fuerte donde importa	Moderada	Productos con niveles de autoservicio y enterprise

Los conceptos de fondo se tratan en aislamiento de tenants en MQTT y en la arquitectura de un broker MQTT multi-tenant.

Decisión 2: diseño de credenciales

Tu modelo de credenciales determina con qué seguridad puedes dar de alta, revocar y rotar dispositivos.

Client IDs por dispositivo. Cada dispositivo necesita un client ID único y estable. Derívalo de un número de serie o de un registro de aprovisionamiento, nunca de un valor aleatorio generado al arrancar, o las sesiones persistentes no se reanudarán.
Sin credenciales en repositorios públicos ni en paquetes de aplicaciones. Las aplicaciones móviles y web no deben contener credenciales del broker a nivel de dispositivo. Haz que llamen a tu API y deja que el backend hable con el broker, o emite credenciales de corta duración y alcance limitado si tu broker lo admite.
Vía de revocación. Cuando un cliente se da de baja o roban un dispositivo, debes poder cortarle el acceso sin tocar los demás dispositivos.
Vía de rotación. Planifica cómo recibe el firmware nuevas credenciales, por ejemplo a través de un topic de configuración autenticado o durante una actualización OTA.

Decisión 3: diseño de topics para el enrutamiento multicliente

Un árbol de topics predecible simplifica el backend y mantiene seguras las suscripciones con comodines. Un patrón que funciona bien:

<customer>/<site>/<device-id>/telemetry
<customer>/<site>/<device-id>/status
<customer>/<site>/<device-id>/cmd
<customer>/<site>/<device-id>/cmd/response

Pautas:

Pon el cliente primero, de modo que un comodín por nivel te dé la vista completa de un cliente.
Mantén los identificadores estables y en minúsculas, sin espacios.
Usa retained messages en status para que los paneles vean el último estado conocido de inmediato.
Usa los response topics y la correlation data de MQTT 5 para los flujos de comando y respuesta, en lugar de inventar los tuyos.
Evita datos personales en los nombres de topic; los topics aparecen en logs y herramientas.

En el modelo A, el nivel de cliente está implícito en el broker, así que puedes eliminarlo del topic o mantenerlo por coherencia entre niveles.

Un servicio de ingesta mínimo para el backend

El backend se suscribe, valida y almacena. Este ejemplo en Python, con paho-mqtt 2.x y MQTT 5, ingiere telemetría de un broker compartido y extrae el cliente del topic. En ConnectMQ Serverless (Paid) puedes escalar horizontalmente estos workers de ingesta con una suscripción compartida como $share/ingest/+/+/+/telemetry, que reparte los mensajes entre los workers.

import json
import ssl
import paho.mqtt.client as mqtt

SUBSCRIPTION = "+/+/+/telemetry"   # usa $share/ingest/+/+/+/telemetry en planes con suscripciones compartidas

def store(customer, site, device, data):
    # Sustitúyelo por la escritura en tu base de datos
    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()

Las integraciones, como bases de datos, notificaciones o analítica, cuelgan de este servicio o de herramientas como Node-RED y Telegraf, que se conectan al broker como clientes MQTT normales.

Construir sobre ConnectMQ

ConnectMQ es un broker MQTT gestionado que encaja con cada uno de estos modelos. Cada broker que creas recibe credenciales generadas y un client ID vinculado a ellas, y los brokers están aislados entre sí en el clúster compartido. Eso hace que el modelo A sea directo: crea un broker por cliente, guarda sus credenciales en tu backend y conecta tu servicio de ingesta a cada uno.

Los límites de los planes se corresponden de forma natural con los niveles de un SaaS. El plan Serverless gratuito admite hasta 25 conexiones, QoS hasta 1 y mensajes de 256 KB, ideal para desarrollo y clientes piloto. Serverless (Paid) admite hasta 1.000 conexiones, QoS 2, mensajes de 1 MB y suscripciones compartidas. Dedicated da a un cliente un clúster aislado, y BYOC ejecuta el broker en una cuenta de nube que controláis tú o tu cliente, gestionado por ConnectMQ.

El portal también ayuda a los equipos de soporte: el explorador de topics en vivo y el cliente MQTT en el navegador te permiten ver qué envían realmente los dispositivos de un cliente, la vista de dispositivos agrupa los equipos por niveles ISA-95 para clientes industriales, y las reglas de alerta por umbral con un registro de alertas señalan los valores fuera de rango.

Checklist de lanzamiento para tu SaaS IoT

Modelo de aislamiento elegido y documentado para cada nivel de precios.
Client ID y credenciales únicos por dispositivo, con un procedimiento de revocación.
Árbol de topics documentado y validado en el backend.
Solo TLS en el puerto 8883 (dispositivos) y 8084 (clientes de navegador).
Reconexión con backoff exponencial y jitter en todo el firmware.
Servicio de ingesta escalado con suscripciones compartidas donde estén disponibles.
Broker de staging separado para pruebas de firmware y backend.
Monitorización y alertas de conexiones y flujo de mensajes por cliente; consulta el checklist de MQTT en producción.

Empieza con ConnectMQ

Crea el prototipo de tu SaaS en un broker Serverless gratuito en app.connectmq.com, sin tarjeta de crédito, y añade un broker por cliente a medida que los vayas firmando. También puedes probar ideas en el servidor MQTT público gratuito antes de crear una cuenta, y leer la guía de broker MQTT en la nube para comparar opciones de alojamiento.

Preguntas frecuentes

¿Debe tener cada cliente del SaaS su propio broker MQTT?

Si los clientes o sus aplicaciones se conectan directamente, o si los contratos exigen separación, sí. Un broker por cliente ofrece un aislamiento aplicado por el propio broker y bajas sencillas.

¿Bastan los prefijos de topic para separar clientes?

Organizan los datos, pero solo los protegen si el broker controla qué prefijos puede usar cada cliente. Sin esa aplicación forzosa, cualquier cliente que se suscriba a # lo vería todo.

¿Cómo escalo el backend que consume los datos de los dispositivos?

Ejecuta varios workers de ingesta con una suscripción compartida de MQTT 5 para que el broker reparta la carga de mensajes entre ellos.

¿Puede mi aplicación móvil conectarse directamente al broker?

Puede hacerlo mediante Secure WebSocket en el puerto 8084, pero evita incrustar credenciales de dispositivo en la aplicación. Pasa por tu API o usa credenciales de alcance limitado por usuario.

MQTT para SaaS IoT: construir una plataforma multicliente sobre un broker MQTT gestionado