Trattare MQTT come una coda ha fatto perdere dati di oltre 200 dispositivi

Un deploy ha riavviato un worker Python per 40 secondi. In quel tempo sono spariti i messaggi di oltre 200 dispositivi. Nessun errore a log, nessuna dead letter, solo dati persi¹.

Il team aveva scambiato il broker MQTT per un sistema tipo RabbitMQ. I dispositivi pubblicavano dati di sensori. Un solo worker si sottoscriveva e scriveva nel database. Finché il worker restava online, tutto ok. Al riavvio, la sottoscrizione si è interrotta e il broker non ha conservato nulla¹.

Il punto tecnico è chiaro: MQTT non è una coda. È un protocollo publish/subscribe leggero. Il broker inoltra i messaggi ai client sottoscritti in quel momento. Se nessuno è in ascolto, quei messaggi non vengono consegnati. Il livello QoS non cambia questo fatto. QoS 0, 1 o 2 gestisce l’affidabilità della consegna sul tratto publisher-broker o broker-subscriber. Non crea una coda per chi è offline. La persistenza durante una disconnessione dipende solo dalla sessione: con clean_session=true in MQTT 3.1.1 il broker elimina le subscription alla disconnessione; in MQTT 5 clean_start=true con session expiry impostata a 0 ha lo stesso effetto. Per mantenere gli arretrati serve una sessione che sopravvive: ad esempio, clean_session=false in 3.1.1 oppure, in 5, clean_start=false e session expiry maggiore di 0¹.

Qui nasce l’errore operativo. In sistemi come Kafka o RabbitMQ i messaggi restano nel log o in coda finché un consumer li legge. Con MQTT no: non esiste una coda centrale che trattiene i messaggi per impostazione predefinita. Se serve un comportamento simile, bisogna configurare la sessione perché duri oltre la disconnessione e capire i limiti della soluzione. Altrimenti basta un riavvio breve per perdere dati di sensori, come è accaduto¹.

QoS non risolve il problema della disconnessione. Un messaggio può avere QoS 1 o 2 e arrivare al broker in modo affidabile, ma svanire se il subscriber non ha una sessione persistente. Alla riconnessione il client riparte pulito, senza arretrati, se la sessione è stata cancellata. In produzione questo si traduce in buchi silenziosi: nessun errore, nessuna coda di rientro, solo misure mancanti¹.

Il caso raccontato è uno di vari incidenti simili. L’insegnamento è di progettazione, non di tuning a fine corsa. Prima di mandare in produzione, bisogna fissare le regole di sopravvivenza della sessione e verificarle con test di riavvio e perdita di connettività. Se la pipeline dipende da un solo worker, il rischio di perdere dati resta alto¹.

Checklist operativa, subito:

• Verificare le opzioni di sessione del client: clean_session su MQTT 3.1.1; in MQTT 5 controllare clean_start e session expiry¹.
• Impostare una sessione persistente quando servono arretrati: 3.1.1 con clean_session=false; 5 con clean_start=false e session expiry > 0¹.
• Ricordare il perimetro del QoS: migliora la consegna sul tratto, non conserva messaggi per client offline¹.

Un test semplice aiuta: simulare un riavvio di 1 minuto del consumer in staging e verificare se, alla ripartenza, riceve i messaggi pubblicati durante l’assenza. Se non accade, la sessione non persiste come pensate¹.