Projetos de IoT têm uma reputação de demorar. Prova de conceito vira piloto interminável, piloto vira projeto paralelo que nunca entra em produção. O caso do Frota Inteligente foi diferente — e a diferença está em decisões de arquitetura tomadas na primeira semana.
O ponto de partida: definir o que vai ao ar primeiro
O cliente precisava monitorar veículos em campo: quilometragem, status operacional e alertas de manutenção preventiva. Existia rastreamento GPS já instalado nos veículos — mas os dados ficavam presos no sistema do fornecedor do rastreador, sem API aberta.
A primeira decisão foi a mais importante: não vamos substituir o hardware. Usamos os dados que já existiam via polling da API do fornecedor, processamos no backend e exibimos no nosso painel. Isso cortou semanas de instalação e homologação de hardware.
Em IoT, a pergunta certa não é "qual hardware ideal?", mas "quais dados já existem e como chegamos a eles?". Substituir hardware custa tempo. Integrar o que já existe custa código.
Semana 1: protocolo, backend e modelo de dados
Com o acesso à API do rastreador confirmado, definimos a stack em dois dias:
- Python + FastAPI — serviço de ingestão com polling configurável (a cada 5 min em operação normal, a cada 1 min para veículos em rota ativa)
- PostgreSQL com TimescaleDB — série temporal para dados de posição e status
- Redis — cache do estado atual de cada veículo (última posição + status)
- WebSocket — para atualização em tempo real no dashboard sem polling do front
Ao final da semana 1, tínhamos dados chegando no banco e um endpoint GraphQL funcional que o front poderia consultar. Nada visual ainda — mas a fundação estava de pé.
Semana 2: dashboard e regras de alerta
O front foi construído em React com visualização de mapa (Leaflet + tiles OpenStreetMap) e painel lateral de status. Cada veículo exibe:
- Posição atual no mapa com atualização via WebSocket
- Status operacional (em rota / parado / manutenção)
- Quilometragem acumulada e projeção para próxima revisão
- Tempo parado acima do threshold configurável
As regras de alerta foram configuradas pelo próprio cliente via painel: distância para manutenção, tempo máximo parado por tipo de veículo, horário de operação esperado. Isso evitou voltas para ajustar código toda vez que uma regra muda.
Semana 3: revisões preventivas e histórico
O módulo de agendamento de revisões foi o que mais consumiu tempo — não pelo código, mas pela lógica de negócio. Cada tipo de veículo tem critérios diferentes: km rodados, horas de operação ou data calendário.
Modelamos como uma árvore de regras configurável em vez de código fixo. O resultado: o gestor consegue adicionar um novo critério sem abrir chamado.
Semana 4: go-live, testes em campo e ajustes
A semana de go-live revelou um problema que não apareceu nos testes: veículos em áreas rurais com cobertura intermitente mandavam pacotes duplicados quando a conexão voltava. O serviço de ingestão precisou de idempotência — filtragem por timestamp + device_id antes de inserir no banco.
É o tipo de problema que só aparece com dados reais. Por isso entregamos em 4 semanas para produção — não para homologação. Produção força os edge cases.
Arquitetura final em produção
Rastreador GPS → API Fornecedor → Serviço Ingestão (Python)
↓
TimescaleDB (histórico)
Redis (estado atual)
↓
GraphQL API + WebSocket Server
↓
Dashboard React (front)O que entregamos ao final
Em produção ao final da semana 4: monitoramento em tempo real de 40+ veículos, alertas automáticos via WhatsApp (usando a API oficial) para o gestor de frota, e histórico de 6 meses de dados de todos os veículos disponível para consulta.
O cliente passou de "não sei onde estão meus veículos" para "tenho visibilidade total e sei qual veículo precisa de manutenção antes que ele quebre".
Entregue dados em produção na semana 1, mesmo que sem interface. Dados fluindo para o banco revelam problemas de integração cedo — onde são fáceis de resolver — em vez de tarde, onde são caros.