O problema
Dois clientes, dois relógios bem diferentes. A autoridade de trânsito de São Paulo precisava de um console web para monitorar e configurar controladores semafóricos pela cidade, onde uma mensagem perdida significa um cruzamento rodando o plano errado. Uma operadora ferroviária precisava saber onde estavam seus vagões de carga ao longo de milhares de quilômetros de trilhos, com posições chegando de um sistema legado via SOAP e sem um mapa para colocá-las.
O que eu fiz
Eu era um de poucos desenvolvedores nos dois projetos. No sistema de trânsito trabalhei no backend que recebia a telemetria dos controladores e enviava configuração, e no console em Angular. No projeto ferroviário construí o geoprocessamento que transformava posições cruas em pontos ao longo do trilho e a interface de mapa que os mostrava. Nos dois fui a pessoa que introduziu testes automatizados no time.
Como resolvi
Mensageria que tolera perda. Os controladores publicavam status via MQTT e o backend assinava tópicos por cruzamento. Os comandos eram idempotentes e carregavam uma versão, então uma mensagem repetida ou atrasada nunca poderia levar um controlador a um plano mais antigo. O estado ficava no MongoDB porque cada modelo de controlador expunha um formato diferente de telemetria.
Geoprocessamento no servidor. As posições dos vagões chegavam como latitude e longitude de um serviço SOAP. Eu as encaixava no segmento de trilho mais próximo e calculava o marco quilométrico, então os operadores viam “vagão 4821 no km 212 da linha de Belo Horizonte” em vez de um ponto no meio do campo. O mapa usava Leaflet com marcadores agrupados para que mil vagões continuassem legíveis.
Testes antes das funcionalidades. Os dois times entregavam sem testes. Configurei RSpec e Capybara do lado Rails, CucumberJS e Karma do lado Angular, e escrevi os primeiros cenários com o vocabulário do próprio cliente para que ele pudesse lê-los. O trabalho novo seguiu o padrão.
O que foi difícil
A integração SOAP. O WSDL da operadora era grande, parcialmente documentado e às vezes errado sobre tipos de campo. Escrever um cliente fino com testes de contrato contra respostas gravadas foi o único jeito de mudar com segurança.
Tempo real no navegador. Manter o console de trânsito atualizado sem martelar o backend exigiu uma mistura cuidadosa de atualizações empurradas para alarmes e polling para o resto.
O resultado
O console de trânsito entrou em uso pelos operadores da cidade. O mapa ferroviário substituiu um processo baseado em planilha para localizar vagões. As duas bases de código ficaram com suítes de teste rodando no Jenkins, que os times mantiveram depois do fim dos contratos.
Onde conferir
Os dois sistemas são internos aos clientes. As abordagens de comandos MQTT idempotentes e encaixe no trilho estão descritas acima, e tenho prazer em aprofundar em conversa.