Da reação à predição: como arquitetar dados logísticos no e-commerce

O problema: decisão reativa custa caro

Numa palestra registrada ao vivo pela redação do iMasters no palco Plenária Tecnologia & Inovação do Fórum E-Commerce Brasil 2026 (transcrição automática disponível na fonte), o expositor descreveu um sintoma que muito dev de backend reconhece: três pessoas pedem o mesmo dado, cada uma recebe um número diferente. O resultado é desconfiança na informação e decisão tomada no escuro.

No contexto logístico do e-commerce, isso vira dinheiro. A fala classificou o modelo antigo como custo reativo: olhar só o passado, apagar incêndio operacional e reagir a falhas de entrega em vez de evitá-las. O cancelamento apareceu como uma das questões críticas do e-commerce (a transcrição é automática e pode conter erros de reconhecimento, mas a ideia é clara). Sem ação rápida diante de uma intercorrência, o prazo prometido ao cliente vira promessa quebrada.

A tese central: sair de uma operação reativa para uma operação preditiva. Antecipar risco e demanda a partir de eventos que já fazem parte do histórico, como alagamentos sazonais que afetam rotas, para recalcular capacidade e replanejar entregas antes do problema estourar.

O caminho: captura, camadas e governança

O desenho apresentado segue um fluxo que vai da captura ao resultado, e é aqui que a arquitetura importa:

• Captura: puxar dados de sistemas operacionais (ERP, WMS, sistemas de atendimento, aplicações internas de roteirização) em tempo quase real.
• Padronização e camadas: organizar em camadas ao estilo medallion (bronze/silver/gold na fala, com ruído de transcrição), tratando e conciliando a informação até chegar numa camada confiável de consumo.
• Governança: catálogo de dados e linhagem, para saber de onde cada número veio.
• Consumo: dashboards, BI e modelos de Machine Learning apoiados numa fonte única de verdade.

O ponto que vale sublinhar para quem constrói backend é o custo do retrabalho de reconciliação. Quando cada área mantém sua própria base, alguém gasta tempo caro só decidindo "quem está certo". Consolidar a verdade num único lugar não é luxo de governança: é remoção de trabalho manual recorrente.

O trade-off que ninguém escapa: latência x custo

A parte mais honesta da palestra foi sobre custo. A stack descrita rodava sobre AWS: ingestão via Kinesis, orquestração com Airflow (a fala menciona algo como "110 fluxos" migrados), processamento com Spark e Redshift como data warehouse. E o Redshift era o gargalo de custo, justamente por ser provisionado para pico.

Quando o volume varia ao longo do dia, da semana e do mês, você provisiona para o momento mais pesado e paga por isso o tempo inteiro. A fala resume uma regra que todo engenheiro de dados deveria ter tatuada:

quanto mais rápido você tem informação no Lake House, mais caro isso custa para a companhia.

Daí a recomendação prática: para cada dado, pergunte qual a velocidade real necessária. Precisa ser real time? Ou uma latência de até uma hora, ou até um dia, resolve? Essa decisão, tomada dado a dado, é o que equilibra o orçamento. Nem tudo precisa de streaming, e tratar tudo como se precisasse é um erro caro.

Leitura crítica para o backend

Algumas observações de quem já manteve pipeline em produção:

1. Fonte única não é banco único. Consolidar a verdade analítica não significa forçar todos os sistemas operacionais no mesmo schema. O valor está na camada de consumo confiável, não em centralizar a escrita.
2. Predição depende de qualidade, não de modelo. Antecipar risco de entrega exige histórico limpo e rotulado. Sem as camadas de padronização, o modelo de ML só automatiza a desconfiança.
3. Provisionamento de warehouse merece revisão. Se o custo dói no pico, vale avaliar modelos serverless ou separação de compute e storage antes de simplesmente aumentar o cluster.

A transcrição não permite atribuir a fala a um palestrante específico nem confirmar todos os números (o material é captação automática e pede confirmação em fonte independente). Mas a espinha do argumento se sustenta: arquitetura de dados logística boa é aquela que casa a latência de cada dado com o que a decisão realmente exige, sem pagar tempo real onde uma hora bastaria.

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