Plataforma de operações de transporte e telemetria
Plataforma de operações de transporte com múltiplos ambientes de cliente e integração com equipamentos de rastreamento veicular.
Case anonimizado: nomes de cliente, dados de infraestrutura e detalhes sensíveis foram omitidos por confidencialidade.
Contexto
Plataforma de operações e telemetria de transporte, com base de código legada em PHP, ambientes isolados por cliente e ingestão contínua de dados vindos de equipamentos embarcados nos veículos. O sistema não pode parar: a operação de transporte depende dele em tempo real.
Desafio
Evoluir e modernizar um sistema em operação contínua sem interromper o negócio. O acoplamento entre módulos tornava qualquer mudança arriscada, a ingestão de telemetria competia por recursos com a aplicação web, e o volume acumulado em MariaDB degradava consultas operacionais.
Meu papel
Senior Software Engineer, com responsabilidades de arquitetura sobre backend, banco de dados e infraestrutura de produção.
Responsabilidades
- Manutenção e modernização das aplicações legadas em PHP.
- APIs backend e módulos de domínio.
- Ingestão e processamento de telemetria.
- Investigação de problemas em produção.
- Bases MariaDB/MySQL de alto volume.
- Serviços containerizados.
- Workers e tarefas agendadas.
- Monitoramento e confiabilidade operacional.
Restrições
- Sistema business-critical: janelas de manutenção curtas e releases controlados.
- Base legada extensa, com módulos fortemente acoplados.
- Ambientes isolados por cliente.
- Ingestão de telemetria contínua, sem tolerância a perda silenciosa de dados.
- Reescrita completa não era uma opção viável.
Arquitetura
- Modernização incremental via Strangler Fig: novos módulos ao lado do legado, com o monolito sendo esvaziado aos poucos.
- Separação da ingestão de telemetria da aplicação web, para que picos de dados não derrubassem a interface operacional.
- Workers assíncronos para processamento fora do ciclo de request.
- Serviços containerizados em Docker Swarm, com deploy mais previsível que o modelo on-premises anterior.
- Rotinas de manutenção e particionamento nas tabelas de maior crescimento.
Principais decisões técnicas
Modernizar por Strangler Fig em vez de reescrever o sistema.
Por quê
O sistema sustenta a operação diária. Uma reescrita exigiria congelar features por meses e assumir o risco de um corte único, sem paridade funcional garantida com anos de regras de negócio implícitas no legado.
Trade-offs
- Convivência prolongada entre código novo e legado, com custo de manutenção duplicado durante a transição.
- Exige disciplina de fronteiras: sem elas, o legado volta a se espalhar.
- Ganho arquitetural aparece de forma gradual, o que é mais difícil de justificar politicamente que um projeto de reescrita.
Isolar a ingestão de telemetria da aplicação web.
Por quê
Ingestão e interface operacional têm perfis de carga completamente diferentes. Compartilhando o mesmo processo, um pico de telemetria degradava a experiência de quem estava operando o transporte.
Trade-offs
- Mais componentes para operar e monitorar.
- Introduz comunicação entre processos onde antes havia chamada direta.
- Ganho claro de isolamento de falhas: um problema na ingestão deixa de derrubar a operação.
Adotar Docker Swarm em vez de orquestração mais complexa.
Por quê
A necessidade era organizar deploys e ganhar visibilidade operacional em uma infraestrutura que vinha de on-premises. Swarm entregou isso com curva de aprendizado compatível com o time e a operação existentes.
Trade-offs
- Ecossistema menor e menos recursos avançados que alternativas mais robustas.
- Decisão adequada ao contexto e ao time daquele momento, não uma escolha universal.
Implementação
- Refatoração de módulos acoplados, com extração de responsabilidades para fronteiras explícitas.
- Workers e tarefas agendadas, com logs estruturados para troubleshooting.
- Redis como apoio para cache e coordenação de rotinas assíncronas.
- Roteamento entre os serviços legados e os novos.
Operação em produção
- Investigação de incidentes com base em logs e métricas, não em suposição.
- Releases controlados, com rollback previsto.
- Monitoramento das rotinas assíncronas. Falha silenciosa de worker é o modo de falha mais caro nesse tipo de sistema.
Resultados
- Reduziu o acoplamento operacional ao separar a ingestão de telemetria da aplicação web.
- Deploys mais organizados e com maior visibilidade após a migração para serviços em containers.
- Sustentou processamento de telemetria de alto volume em ambiente de produção contínua.
- Melhorou a manutenibilidade do legado por refatoração incremental, sem interromper a operação.
Stack
- PHP
- MariaDB
- MySQL
- Redis
- Docker Swarm
- Linux