Tire de cena as apresentações dos fornecedores e toda integração de ERP para comércio é uma de duas arquiteturas. Na primeira, a loja lê do ERP no momento da requisição: um comprador autenticado abre uma página de produto e a plataforma pergunta ao ERP, naquele instante, quanto este cliente paga e o que há em estoque. A Sana Commerce é construída assim. Na segunda, um conector copia catálogo, preços e estoque do ERP para o próprio banco de dados da plataforma de comércio, de forma agendada ou via webhooks. A loja então serve essa cópia. BigCommerce, Adobe Commerce e a maioria das plataformas funcionam dessa forma, com middleware entre os dois sistemas.
Construímos as duas. Já entregamos lojas Sana que leem preços ao vivo do Business Central e do S/4HANA, e já construímos lojas BigCommerce sincronizadas por middleware nas quais um conector mantém o catálogo no ritmo do ERP. Nenhuma é "a resposta certa" no abstrato. Elas falham de modo diferente, custam de modo diferente, e cada uma é claramente correta para alguns negócios e silenciosamente errada para outros. Esta é a comparação honesta.
Os dois modelos, com precisão
A forma mais limpa de defini-los é por onde vive fisicamente, no instante em que a página é renderizada, a resposta para "quanto este cliente paga por este item agora".
No modelo de leitura ao vivo (tempo real), a resposta vive no ERP, e a loja não a tem até perguntar. Cada preço autenticado, cada número de estoque, cada verificação de crédito é uma ida e volta ao sistema de registro. Existe exatamente uma cópia da verdade, e a loja nunca é dona dela. Este é o padrão ERP primeiro sobre o qual escrevemos em outro lugar no contexto da Sana Commerce.
No modelo de middleware (sincronização), a resposta vive no banco de dados de comércio, escrita ali antes por um conector que a leu do ERP. A loja possui uma cópia. Essa cópia está tão fresca quanto a última sincronização que a tocou. O ERP está a montante e, no momento da requisição, fora do circuito. É assim que a maioria das integrações de ERP com BigCommerce é construída.
Todo o resto decorre dessa única diferença. Guarde-a, porque quase cada compensação abaixo é apenas uma consequência de onde os dados ficam.
Exatidão: uma única fonte de verdade frente a uma cópia gerenciada
A leitura ao vivo é correta por construção. Se o preço mudou no ERP há um segundo, a próxima renderização da página vê o novo preço, porque a renderização da página é a consulta. Não há janela alguma durante a qual a loja esteja confiantemente errada. Para B2B, onde o preço é frequentemente específico de cada cliente (tarifas de contrato, faixas por volume, ajustes negociados) e onde errar um preço de contrato é uma disputa de faturamento, este é um benefício real e subestimado.
O modelo de middleware é correto entre sincronizações e desvia no intervalo. O tamanho da janela de desvio é uma decisão de projeto: um conector movido a webhooks pode empurrar uma mudança de preço em segundos, enquanto uma tarefa noturna de catálogo deixa você até um dia desatualizado. A maioria dos sistemas reais é uma mistura, e o enquadramento honesto não é "é exato?", mas "qual é o seu pior caso de desatualização e o negócio consegue tolerá-lo para estes campos em particular?". Estoques que pulam de 4 para 0 entre sincronizações são o caso doloroso clássico, porque o cliente que pediu a unidade fantasma só descobre na hora da entrega.
Desempenho: o ERP está no caminho da requisição, ou não está
É aqui que o modelo de middleware vence com clareza. Servir um preço do seu próprio banco de dados, ou de um cache à frente dele, é rápido e previsível. Você pode colocar uma CDN à frente das páginas de navegação anônima e nunca incomodar o ERP. A latência da página fica desacoplada de como o ERP está se sentindo hoje.
A leitura ao vivo coloca o tempo de resposta do ERP no caminho crítico da página. Uma plataforma como a Sana mitiga isso com força por meio de cache e pool de conexões, e para catálogos B2B típicos (compradores autenticados na casa das centenas a poucos milhares, não milhões de sessões anônimas) não é um problema. Mas o teto da velocidade da sua página é definido pelo ERP, e se o ERP for uma máquina local muito carregada, você sente. A mitigação é disciplina arquitetural: mantenha as páginas de navegação anônima cacheáveis e reserve a ida e volta ao vivo para os momentos que de fato precisam dela, como um preço autenticado ou uma verificação de estoque ao adicionar ao carrinho.
Resiliência: o que acontece quando o ERP está fora
Esta é a pergunta que a maioria das avaliações pula, e é a que morde mais forte no segundo ano.
No modelo de leitura ao vivo, o ERP é uma dependência rígida para as partes do site que leem dele. Se o ERP cai para manutenção ou tomba, o preço autenticado e o estoque ao vivo degradam junto. Boas implementações suavizam isso com fallbacks em cache e mensagens elegantes, mas você não pode fingir que a loja é plenamente independente, porque arquiteturalmente ela não é. O tempo de atividade da sua loja, para os recursos mais acoplados ao ERP, é limitado pelo tempo de atividade do seu ERP.
No modelo de middleware, a loja continua servindo sua cópia enquanto o ERP está fora. Navegação, preços e estoque em cache seguem funcionando. O problema está no outro sentido: os pedidos feitos durante a indisponibilidade têm de ir para algum lugar. Um conector bem construído os enfileira e os posta quando o ERP retorna, o que significa que o seu caminho de postagem de pedidos precisa ser durável e idempotente (mais sobre isso abaixo). Um mal construído os perde ou os posta em duplicidade. O desacoplamento te compra resiliência do lado da leitura e te entrega em troca um problema de enfileiramento do lado da escrita.
Preços específicos de cliente: o ponto crucial do B2B
Esse único requisito decide mais arquiteturas do que qualquer outro. Em B2B, o preço costuma ser função de quem está perguntando: preço de contrato, faixas por volume, regras específicas de local de entrega, ajustes promocionais que a equipe de vendas mantém no ERP.
A leitura ao vivo lida com isso de forma nativa, porque o contexto do cliente faz parte da consulta. Você pergunta ao ERP por "este cliente, este item, hoje" e recebe a resposta que o ERP daria, sem um motor de preços para reconstruir. O middleware tem de replicar a lógica de preços, ou ao menos as listas de preços resolvidas, dentro da plataforma de comércio. Para algumas listas de preços simples isso é trivial. Para uma matriz profunda de regras de contrato específicas de cliente, replicá-la com exatidão (e revalidá-la sempre que as regras do ERP mudam) vira um projeto por si só, e é exatamente o tipo de segundo motor de preços que desvia. Este é o argumento individual mais forte a favor da leitura ao vivo em B2B com muitos contratos, e o lugar onde as equipes mais subestimam o desenvolvimento do middleware.
Custo e complexidade
Nenhum modelo é gratuito, e eles gastam seu orçamento em lugares diferentes. A leitura ao vivo concentra custo no conector do ERP e no desempenho do ERP: você precisa que o ERP responda rápido e de forma confiável sob carga web, o que às vezes significa ajustes no lado do ERP ou capacidade que você não planejou. O middleware concentra custo na pipeline de dados do conector: as tarefas de sincronização, o mapeamento de campos, a lógica de conflito e invalidação, e o monitoramento que avisa quando a sincronização desviou. O middleware ainda acrescenta uma superfície operacional que a leitura ao vivo simplesmente não tem, a saber, um sistema de sincronização que ele mesmo pode quebrar, atrasar ou parar em silêncio, e que portanto precisa dos próprios alertas. O erro recorrente é orçar a construção do conector e esquecer o imposto operacional permanente do conector.
Fazer o middleware parecer tempo real
A maioria das plataformas é de middleware, então a pergunta prática geralmente não é "como evito o middleware" e sim "como faço uma loja sincronizada se comportar como uma ao vivo onde importa". Três técnicas fazem a maior parte do trabalho.
Cacheie com invalidação explícita, não só com expiração. A expiração baseada em tempo garante desatualização até o TTL. O melhor padrão é deixar que as mudanças do ERP invalidem ativamente as entradas de cache relevantes via webhooks, de modo que uma mudança de preço ou de estoque empurre uma invalidação em vez de esperar um temporizador. A expiração então vira uma rede de segurança, não o mecanismo principal. A parte difícil é o escopo da invalidação: uma única mudança de preço de contrato pode tocar muitas entradas calculadas, e acertar o raio de impacto é a engenharia de verdade.
Chamadas ao vivo ao visualizar SKUs sensíveis. Você não precisa de tudo ao vivo. Identifique os campos e itens onde errar sai caro (itens com preço de contrato, SKUs de baixo estoque ou feitos sob encomenda, qualquer coisa com trava de crédito) e faça uma chamada ao vivo direcionada ao ERP só para esses, só nas páginas em que aparecem. O resto do catálogo segue em cache e rápido. Isso pega de forma seletiva a exatidão do modelo de leitura ao vivo justamente onde ela se paga, que costuma ser a mistura certa.
Postagem de pedidos idempotente e durável. Com qualquer modelo com o qual você leia, o caminho de escrita de volta ao ERP precisa ser seguro para repetir. Dê a cada pedido uma chave de idempotência estável, enfileire as postagens de forma durável e faça o manipulador do lado do ERP rejeitar duplicatas em vez de criar um segundo pedido de venda. É isso que permite sobreviver a quedas do ERP e reinícios do conector sem postar pedidos em duplicidade, e importa nos dois modelos, mas é inegociável para o middleware porque a fila está fazendo trabalho real durante cada soluço do ERP.
Um framework de decisão
Esta é a versão curta que de fato usamos, em prosa e não em tabela. Incline-se para a leitura ao vivo quando o ERP guarda preços profundos específicos de cliente ou de contrato que você não quer reconstruir, quando o disponível-para-promessa em tempo real e o estado de crédito realmente condicionam as vendas, quando seu público é em sua maioria de compradores autenticados e não de navegantes anônimos, e quando seu ERP consegue responder rápido sob carga. Incline-se para a sincronização por middleware quando a maior parte do tráfego é navegação anônima de catálogo que deveria ter velocidade de CDN, quando os preços são simples o bastante para serem replicados como um punhado de listas de preços, quando você precisa que a loja continue vendendo enquanto o ERP está offline, ou quando o ERP não consegue receber tráfego web ao vivo. E recorra ao híbrido (sincronize o grosso, chame ao vivo os poucos sensíveis) quando você tem um catálogo anônimo rápido mas uma cauda de itens com preço de contrato ou de baixo estoque que precisam ser exatos. O que evitar é escolher um modelo e depois operá-lo como se fosse o outro: cachear uma plataforma de leitura ao vivo até que ela vire em segredo uma cópia desatualizada, ou parafusar tantas chamadas ao vivo em uma plataforma de middleware que você reconstruiu a dependência do ERP sem a garantia de fonte única.
O que isso significa para os compradores
A plataforma que você escolher já tomou essa decisão por você, na maior parte. A Sana é leitura ao vivo. BigCommerce e Adobe são middleware. Então a decisão real está a montante: seu negócio roda sobre o ERP a ponto de uma cópia ser um passivo, ou o ERP é leve o bastante para que desacoplar seja puro ganho? Responda isso com honestidade e a lista curta de plataformas quase se escreve sozinha. Se você está pesando exatamente isso, a nossa comparação entre Sana Commerce e BigCommerce percorre a mesma bifurcação pelo lado da plataforma.
Se você está dimensionando isso em um projeto real e quer uma resposta direta sobre qual modelo encaixa, esse é o trabalho que fazemos. Comece uma conversa aqui.