Do full scan diário ao CDC contínuo: anatomia de uma migração de dados logísticos

Na Plenária Tecnologia & Inovação do Fórum E-Commerce↳E-commerce21 conteúdosECBR Club: novo espaço para devs se conectarem ao ecossistema de e-commerceDev (Back & Front) · mai 2025TOTVS anuncia joint venture com VTEXMarketing Tech · mai 2019Jovens da Brasilândia recebem formação gratuita em tecnologiaGestão Dev & TI · jul 2025Ver tudo em Marketing Tech → Brasil 2026, uma palestra sobre data-driven fulfillment detalhou a reforma de uma arquitetura de dados logísticos que já tinha oito anos de vida. O relato, captado ao vivo pela redação do iMasters, vale menos pelos números específicos (a transcrição é automática e tem ruído) e mais pelo padrão de decisão, que se repete em qualquer empresa que cresceu 10x em cima de um design pensado para uma escala menor.

O ponto de partida: arquitetura que envelheceu junto com a empresa

O diagnóstico é familiar. A arquitetura começou a ser construída há uns oito anos, quando a companhia era cerca de dez vezes menor, e foi sendo remendada componente a componente sem que ninguém parasse para revisá-la como um todo. O resultado acumulado: latência de D-1 (a decisão de hoje sempre olhava o dado de ontem), custo fixo alto e um pipeline com 110 componentes.

O detalhe técnico mais interessante é a carga imposta ao banco transacional. O ingest de dados fazia full scan diário nas tabelas de origem, competindo por recurso com a operação. Quando a aplicação não tinha réplica dedicada para leitura analítica, essa disputa degradava a própria operação logística. É o clássico acoplamento entre OLTP e analytics que parece inofensivo em pequena escala e vira gargalo quando o volume cresce.

O que mudou: CDC, medalhão e menos peças

A reforma migrou para uma stack de lakehouse em nuvem, organizada no padrão medalhão (bronze, silver, gold). As mudanças estruturais:

• Full scan diário virou CDC contínuo. Em vez de varrer o banco, o pipeline passou a ler o log de replicação (o binlog, no caso de MySQL↳MySQL8 conteúdosMySQL + Adminer + Docker Compose: montando rapidamente um ambiente para usoData · abr 2019Banco de dados MYSQL no PHPStormDev (Back & Front) · jul 2019Criando um ambiente de desenvolvimento PHP mínimo com Docker – Parte 3Dev (Back & Front) · out 2019Ver tudo em Data →). Isso derruba a carga sobre o transacional e troca latência de horas por latência de minutos.
• Camada gold como contrato. Dados curados e confiáveis expostos para as áreas de negócio, em vez de metadados espalhados por vários sistemas.
• Consolidação radical. De 110 para 22 componentes, com cenários pontuais caindo de cinco peças para duas. Menos componentes significam menos pontos de falha e menos superfície para manter.

O modelo final é híbrido, e isso é o mais honesto do relato: nem tudo virou tempo real. A equipe classificou cada consumo por necessidade (real-time, algumas horas, D-1, D-7, D-30) e só pagou o custo de CDC onde a latência realmente importa. Segundo os números citados, são 13 streams ativos puxando 99 tabelas replicadas, com tempo médio de propagação de 15 minutos. Ou seja: não replicaram 100% da base, replicaram o que alimenta a decisão.

Por que a latência importa em logística pesada

O exemplo dado no palco explica o valor de negócio melhor que qualquer métrica. Com produtos leves, uma entrega frustrada tem saídas (deixar com vizinho, caixa de correio). Com um armário de seis volumes de 35 a 40 kg, não há plano B improvisado: é preciso contato rápido com o cliente. Sem dado em tempo hábil, a torre de controle e o atendimento operam no escuro.

O caso concreto: cliente recebe cinco dos seis volumes corretos e um trocado por engano. Percebe na hora e aciona o atendimento. Com dado fresco, dá para identificar o motorista e disparar a correção rápido. Isso é latência de dados virando SLA. A palestra menciona um ganho de três pontos percentuais de SLA, que em e-commerce é discussão de reporte executivo semanal.

O que raramente aparece no slide de vitória

O trecho mais útil para quem for tentar algo parecido é a lista de dores, não a de ganhos:

• Legado sem documentação. Sistemas de 8 a 10 anos, criados quando a empresa era menor, sem conhecimento consolidado. A equipe credita à IA↳Inteligência artificial440 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025IA generativa e a urgência de reconstruir nossa relação com a verdadeAI · jun 2025Ver tudo em AI → parte da engenharia reversa para quebrar esse gap de conhecimento.
• Decisões iniciais erradas. Mesmo com consultoria especializada indicada pelo provedor de nuvem, houve descompasso: os especialistas não conheciam a operação e a equipe não dominava a tecnologia. O resultado, segundo o relato, foi ter que parar, revisitar e descartar boa parte do trabalho já feito.
• Coexistência dupla. Durante a migração gradual (que começou pela logística, a área de maior dor), o time manteve arquitetura nova e legada rodando em paralelo. A imagem usada foi jogar futebol e ler ao mesmo tempo.

Esse é o trade-off que costuma ficar de fora das apresentações de arquitetura: migração incremental reduz risco de big bang, mas cobra o preço de operar dois mundos simultâneos por um bom tempo. Consultoria de fornecedor acelera, mas não substitui o conhecimento do próprio domínio. E CDC não é a resposta universal, é a ferramenta certa só onde a latência paga a conta. O contexto, de novo, é rei.

Como a transcrição foi captada por reconhecimento automático, nomes, siglas e números podem conter erro; trate as métricas como ordem de grandeza, não como dado auditado.

Fonte: Transcrição ao vivo — Plenária Tecnologia & Inovação (14:30–15:00)