Sua operação cresceu. Sua arquitetura acompanhou?

Como identificar uma arquitetura de e-commerce fragmentada e organizá-la em fases, sem trocar tudo de uma vez.

por Júlia Mafra

Toda empresa que vende online chega a um ponto em que perguntas simples deixam de ter resposta rápida. Quanto temos em estoque? Que preço esse cliente paga? Esse pedido já foi faturado? No varejo, o ERP mostra um saldo, a loja física mostra outro e o marketplace já vendeu a última unidade. No B2B, o representante fecha o pedido com uma condição que o portal desconhece, o financeiro libera crédito consultando uma planilha e o cliente precisa ligar para saber onde está a entrega.

Nenhum desses problemas nasce de uma decisão errada. Eles se acumulam a partir de escolhas razoáveis, feitas uma de cada vez: um app para calcular frete, um conector para o marketplace, uma integração com o ERP, um portal B2B montado às pressas, uma planilha para cobrir o que nenhum sistema faz. O faturamento cresce, os canais se multiplicam e a arquitetura continua a mesma do primeiro ano.

O custo aparece aos poucos: venda sem estoque, pedido refeito à mão, time de tecnologia ocupado consertando integração e projeto novo que leva meses para sair do papel. Este artigo mostra como reconhecer esses sinais, seja numa loja DTC, num marketplace ou num portal B2B, e como reorganizar a arquitetura em fases, sem trocar tudo de uma vez. A base é o material que a Shopify vem publicando sobre o tema, somado ao que observamos em operações brasileiras.

01Frankenstack: o que é e por que acontece

A Shopify usa o termo frankenstack para descrever uma pilha de soluções pontuais que não opera como um sistema (Shopify, 2026). Cada ferramenta entrou para resolver um problema específico e foi conectada pela integração mais rápida disponível naquele momento.

O artigo aponta que os problemas aparecem nas conexões, e não nas aplicações. Uma atualização de API interrompe a sincronização entre checkout e ERP sem gerar alerta. Uma mudança de preço chega ao site e não chega ao PDV. O teste sugerido é direto: se a atualização de um único fornecedor consegue interromper o fluxo entre checkout, ERP e expedição, a pilha já é um frankenstack.

02Omnichannel, integração, composable e unified commerce

Esses termos aparecem juntos com frequência, mas descrevem coisas diferentes.

Um teste prático ajuda a separar os conceitos: se o dado do cliente precisa de algum tipo de sincronização para estar atualizado, a operação tem integração, e não unificação. O PDV merece atenção especial. Mesmo com loja virtual e OMS bem integrados, a operação continua fragmentada se a loja física roda em outro sistema.

Já a Shopify diferencia composable de frankenstack pelo que existe em volta das peças. Composable exige contrato de API, dono por componente, versionamento, modelo de dados padronizado e observabilidade. Um frankenstack pode ter as mesmas ferramentas, mas sem nada disso.

03Sinais de que a arquitetura ficou para trás

A Shopify publica um checklist de diagnóstico. Adaptamos para os padrões que mais encontramos no Brasil:

• Ninguém consegue desenhar todas as ferramentas e como elas se conectam.
• Não há fonte única de verdade para cliente, pedido, produto ou estoque.
• Estoque é atualizado por ERP, WMS e hub de marketplace de forma independente.
• A sincronização é feita por polling em lote, com janelas que geram overselling em pico.
• O mesmo dado é digitado manualmente em mais de dois sistemas.
• Publicar um SKU ou abrir um canal exige mexer em quatro ou mais plataformas.
• Integrações não têm dono, log centralizado nem alerta de falha.
• Uma mudança de API de fornecedor já quebrou um fluxo crítico nos últimos 12 meses.
• O time de tecnologia gasta mais tempo mantendo integrações do que construindo funcionalidades.

04O peso do B2B e dos pagamentos

No B2B, a fragmentação costuma ser maior. É comum encontrar soluções costuradas sobre sistemas legados para cobrir requisitos básicos, o que gera estruturas frágeis e compromete a qualidade dos dados. Ao mesmo tempo, o comprador espera autoatendimento, fluxos de aprovação, contas com múltiplos usuários e permissões por papel.

Na prática, isso aparece como tabelas de preço por cliente mantidas no ERP, condições de pagamento negociadas fora do sistema e limite de crédito consultado manualmente antes de liberar o pedido.

Em pagamentos, o cenário brasileiro adiciona camadas próprias: Pix, cartão parcelado, boleto, split entre sellers, antecipação de recebíveis e mais de um adquirente. Quando cada meio de pagamento chega ao financeiro por um extrato diferente, a conciliação vira trabalho manual e o fechamento atrasa.

05Mapeando os sistemas de registro

A etapa que mais revela problemas é definir, para cada domínio de dado, qual sistema é a fonte de verdade. A Shopify recomenda registrar quem escreve, quem lê, a frequência de sincronização e o atraso aceitável. A tabela abaixo é um exemplo de ponto de partida; os valores mudam conforme a operação.

06Padrões de integração que reduzem fragilidade

Com os sistemas de registro definidos, o próximo passo é padronizar como o dado circula. Alguns critérios que usamos:

07Um roteiro em cinco fases

Não é preciso substituir tudo. A modernização pode acontecer em fases, sem ruptura. A Shopify afirma que unificar o núcleo não exige trocar ERP ou WMS, desde que eles se conectem por integrações governadas. O roteiro que ela propõe:

1. 01Inventário. Toda ferramenta, com custo anual, data de renovação, dono e integrações, incluindo scripts e automações. Ferramentas sobrepostas viram candidatas a desativação.
2. 02Sistemas de registro. O mapa descrito acima, com regra de resolução de conflito entre sistemas.
3. 03Padronização de integrações. Os critérios da seção anterior, aplicados primeiro aos fluxos de maior volume.
4. 04Unificação do núcleo. Catálogo, checkout, PDV e gestão de pedidos, que afetam todas as áreas.
5. 05Governança. Toda ferramenta nova passa por revisão: a qual sistema de registro se conecta, o que duplica, quem mantém a integração e como será monitorada.

Para acompanhar a evolução, a Shopify sugere quatro indicadores: velocidade de lançamento de produtos e campanhas, taxa de incidentes de integração, taxa de falha em mudanças de integração e custo operacional por pedido.

08E a inteligência artificial?

Agentes de IA para atendimento, previsão de demanda ou reposição dependem de dados consistentes. A Shopify dá um exemplo concreto: uma ferramenta que lê estoque do ERP enquanto o PDV mostra outro saldo, por causa de atraso na sincronização, vai recomendar reposição com base em dado desatualizado. Organizar a arquitetura vem antes de qualquer projeto desse tipo.

Referências

Frankenstack: What It Is and How To Fix It — Shopify, abril de 2026