Sync de PDV legado sem parar a operação
Uma cervejaria precisava mostrar o ranking de consumo na TV do bar. Os dados vinham do PDV — o sistema antigo do estabelecimento. O equipamento era uma TV Box Android ligada 24 horas; a internet caía; o PDV reiniciava todo dia. Desligar tudo para migrar era arriscado: o bar não podia parar.
Este post descreve o que fiz no projeto Batalha dos Barris: em vez de trocar o sistema de uma vez, substituí partes aos poucos, com um agente de sincronização separado.
Contexto
- Onde os dados nascem: MySQL do PDV (sistema legado; não controlamos o deploy).
- Onde os dados vão: PostgreSQL + API em Flask + player Angular (PWA) na TV Box.
- O que o negócio esperava: ranking atualizado com frequência, sem precisar de alguém na TV mexendo no código.
Se a sincronização para, o ranking congela — e isso fica visível para quem está no bar.
Como ficou a arquitetura
MySQL do PDV → Agente Python (SSH) → PostgreSQL → API Flask → App Angular na TV Box
- O player na TV não acessa o MySQL legado direto.
- O agente cuida da conexão SSH, dos reinícios do PDV e do ponto onde parou a sync.
- A API usa cache para não sobrecarregar o player com requisições.
Optamos por sincronização em intervalos fixos em vez de conexão ao vivo (websocket). Em uma TV Box com internet instável, isso é mais simples e confiável.
Problemas que apareceram
Internet cai no agente: o sync precisa continuar do último ID ou horário confirmado — sem reprocessar tudo nem pular vendas.
PDV reinicia: o agente reconecta e valida o ponto de retomada; o player mostra o último dado em cache.
Atraso nos dados: hoje descobrimos pelo log; se eu fizer de novo, colocaria alerta quando o atraso passa de um limite aceitável.
O que eu levo para outros projetos
- Retomar de onde parou precisa ser requisito desde o início, não algo para depois.
- Sync incremental com intervalo tolerante a falhas curtas de rede.
- Isolar falhas: legado, agente, API e player não devem derrubar um ao outro.
- Próximo passo: medir atraso e falhas por etapa.
