Levar 14 mil telas para o MQTT sem perder nenhuma

O medo

Cada tela da rede conversa com a plataforma de dois jeitos. Um é a prova de exibição: o log de cada anúncio, guardado no aparelho e enviado em lote, que é o que a gente fatura. O outro é presença e telemetria: "estou viva, este é meu estado", uma mensagem pequena, mandada o tempo todo por cada player via HTTP. Por trás, cada mensagem ia para um tópico no Kafka e de lá para o ClickHouse.

Esse segundo canal também é como a gente sabe que uma tela existe. Se uma mudança quebra esse canal num player, a tela continua passando o que tinha, e a gente para de enxergá-la. Não dá para mandar uma correção, porque ela iria pelo mesmo canal que acabou de quebrar. Com cerca de 14 mil telas em elevadores e shoppings, uma versão ruim ali pode virar técnico visitando milhares de prédios, que para uma empresa como a nossa é o pior cenário possível.

Por isso, quando decidimos levar presença e telemetria para o MQTT, a parte técnica era a menor. O projeto era não perder contato com nenhuma tela.

Um ano para trocar um protocolo

Levou o ano inteiro. O primeiro teste de mockup é de março. Depois a mudança se espalhou pelo player, pelos servidores e por muitos processos que dependiam do jeito antigo de uma tela se anunciar, e cada um teve que migrar ou ser adaptado.

Vieram então uns quatro meses de teste antes de qualquer tela real. Depois, um piloto numa parte pequena da frota, uma semana dele rodando sem incidente, e um rollout controlado a partir dali. O último passo foi em 30 de setembro de 2026.

Meu papel foi liderar. Eu estava ocupado com outros projetos nesses meses, então um engenheiro sênior do time fez a maior parte da mão na massa, e eu dei a direção e discuti cada passo com ele antes de ir para o ar. A pergunta por trás de todo passo era a mesma: o que acontece com uma tela se isso der errado, e como a gente chega nela depois.

Como a gente soube que funcionou

O degrau aparece nos dados em que a gente já confiava. As linhas de telemetria chegando no ClickHouse caíram de cerca de 1,7 milhão por hora para cerca de 0,6 milhão por hora, por volta das 16h do dia da virada, e ficaram ali. Esta é a consulta que usei, com nomes genéricos:

SELECT
    toStartOfHour(event_time) AS hour,
    sum(rows)                 AS rows_in
FROM system.part_log
WHERE event_type = 'NewPart'
  AND database = 'logs' AND table = 'device_presence'
  AND event_time >= '2026-09-29' AND event_time < '2026-10-02'
GROUP BY hour
ORDER BY hour;

Uma queda sozinha não prova nada. A mesma queda acontece se metade da frota ficar muda, então a queda foi a segunda coisa que conferi. A primeira é o número de telas distintas reportando: em 5 de outubro, 13.835 aparelhos mandaram telemetria em 24 horas, a mesma frota de antes da virada. A contagem de mensagens no Kafka nessas 24 horas foi de 13.912.374, contra cerca de 42 milhões por dia de abril a setembro, ou −67%. Na conversa eu arredondo para "quase 70%".

SELECT
    toDate(received_at)   AS day,
    uniqExact(device_id)  AS screens,
    count()               AS messages
FROM logs.device_presence
WHERE received_at >= today() - 3
GROUP BY day
ORDER BY day;

A telemetria bruta fica só alguns dias no ClickHouse, então para o lado do "antes" você precisa de números guardados antes. O part_log guarda o histórico do que foi inserido, e é por isso que gosto dele para esse tipo de conferência (ele precisa estar ligado na configuração do servidor, então confira se a system.part_log existe antes de contar com ela).

O que eu repetiria

• Quando a mudança mexe no canal que você usa para consertar as coisas, planeje primeiro o caminho de volta. O rollback não pode depender do canal novo funcionando.
• Deixe o caminho de faturamento fora da migração. A prova de exibição não mudou uma linha, então um problema na presença nunca poderia virar problema na fatura.
• Meça com os instrumentos em que você já confia, e confira a contagem de aparelhos antes da contagem de mensagens.
• Liderar uma coisa que você não digita é trabalho de tempo integral. Revisar cada passo com quem estava fazendo pegou mais coisa do que qualquer plano de teste que eu escrevesse sozinho.

Arquivado pelo problema que resolve

• mqtt
• gestão de frota
• rollout
• telemetria
• kafka
• clickhouse
• liderança