Pular para o conteúdo
Operating Intelligence 12 min de leitura

Composable, MACH e headless: quando vale decompor

A decisão é de caixa antes de ser de engenharia. É a régua que protege seu caixa. Ela cobre o custo total de manter tudo em cinco anos, o motivo certo para migrar e o ponto em que separar destrói mais valor do que libera.

AC

Alexandre Caramaschi

Founder da Brasil GEO, ex-CMO da Semantix (Nasdaq), cofundador da AI Brasil

Atualizado em 10 de junho de 2026

Este guia é para quem tem loja online e ouviu que precisa trocar o sistema por vários sistemas menores. Você vai ver quando a troca devolve dinheiro, quanto ela custa em cinco anos e quando ficar como está sai mais barato.

O cenário deste guia é uma joalheria que vende online e na loja física. Ela muda o preço das peças toda semana, conforme a cotação do ouro, e a mudança demora dias para entrar no site. Esse atraso é o que custa dinheiro.

A ideia geral por trás dessa arquitetura está no guia Composable commerce: a base técnica do e-commerce agent-ready. Aqui a conversa é outra: quando trocar, quanto custa a conta cheia e onde a troca deixa de compensar.

O que quer dizer separar o sistema da loja em pedaços?

Separar o sistema em pedaços quer dizer trocar um programa único, que faz tudo, por várias peças que conversam entre si. Cada peça cuida de uma coisa: a busca, o preço, o carrinho, o pedido. Você troca uma peça sem mexer nas outras.

O vendedor vai usar três palavras. MACH é o apelido de quatro princípios técnicos e importa pouco para você. Headless é trocar só a vitrine do site, sem mexer no que fica atrás do balcão. Composable é separar também o que fica atrás.

Headless e composable, sem confusão

HeadlessDesacopla só o frontend do backend via API: troca a vitrine sem mexer no resto.
ComposableDecompõe o próprio backend em capacidades independentes: busca, pricing, checkout, pedidos.
A relaçãoTodo composable é headless; nem todo headless é composable.

Os números do mercado mostram a direção. Entre grandes empresas, 87% já adotaram esse modelo de forma ampla e 9 em cada 10 tiveram o retorno que esperavam. Em 2025, 70% dos projetos novos entre empresas já nasceram desse jeito.

O detalhe que o número esconde é o tamanho da empresa. Quem colhe esse retorno costuma ter várias equipes de tecnologia trabalhando ao mesmo tempo. A loja de médio porte no Brasil quase nunca tem isso, e por isso a régua muda.

Separar o sistema serve a um fim de caixa: responder mais rápido ao mercado sem que cada mudança ameace o carrinho. Quando a separação não acelera nenhuma resposta que importa, ela só acrescentou contas a pagar.

Direção do enterprise (MACH Alliance)

  • Empresas enterprise que já implementaram MACH amplamente87%
  • Novas implementações B2B de 2025 que nasceram composable ou API-first70%
  • Organizações cujo ROI atendeu ou superou a expectativa9 em 10
Fonte: MACH Alliance, janeiro de 2025 (561 decisores)

Quando separar uma parte vale o dinheiro?

Vale quando uma parte do sistema tem fila de mudanças e essa fila está segurando venda. O candidato é quase sempre o mesmo trio: a busca, o preço e o carrinho. Fora desse trio, a separação raramente se paga.

Veja o mecanismo na joalheria do cenário. Para mudar a ordem dos produtos na busca, a agência precisa publicar o sistema inteiro. Isso abre risco no carrinho, então a equipe adia. A busca fica parada justamente onde o cliente decide se acha a peça.

Existe um número para isso: quantas vezes por semana a equipe consegue publicar mudança com segurança. Nas empresas rápidas isso acontece várias vezes por dia. No sistema travado acontece uma vez por trimestre, e o negócio demora um trimestre para reagir.

Qual parte separar primeiro?

Comece onde a demora machuca mais o caixa. Primeiro a busca, porque é ali que o cliente encontra ou desiste. Depois o preço e a promoção, porque é ali que mora a margem. O carrinho fica por último, porque mexer nele dá o maior risco.

A ordem prática de decomposição

  1. Busca e merchandisingOnde mora a descoberta.
  2. Pricing e promoçãoOnde mora a margem.
  3. Checkout, por últimoOnde mora a conversão e o maior risco de mexer.
  4. Catálogo, cadastro e conteúdo ficamMudam devagar e quebram pouco: raramente justificam decomposição isolada.

A regra surpreende quem ouviu que tudo tem de ser modular. Você não separa o que é estável e funciona. Na joalheria, o preço muda toda semana pela cotação do metal, então vale separar. O cadastro de fornecedores muda uma vez por ano e fica onde está.

Volátil ou estável

  • Sea capacidade muda toda semana e decide a margem (regra de preço por quilatagem e cotação de metal)
    entãocaso forte para pricing como serviço
  • Sea capacidade é estável e funciona (o cadastro de fornecedores)
    entãonenhum caso para virar microsserviço

Quanto custa de verdade, somando cinco anos?

A conta não é só a mensalidade dos sistemas. Some também o trabalho de ligar, vigiar e atualizar cada conexão entre as peças. Essa segunda parte não aparece na proposta e é ela que decide se a conta fecha.

A mensalidade de cada peça pode até ser menor que a do sistema único. O que engorda a conta é a ligação entre as peças. Cada peça nova traz uma API (a porta por onde dois sistemas trocam informação sozinhos).

Junto com a API vem um contrato para atualizar, um ponto a mais para quebrar e um fornecedor a mais para cobrar. O guia de integration layer e event bus mostra essa parte em detalhe.

O que cada serviço novo acrescenta

Um endpointPara manter no ar.
Um contratoPara versionar quando muda.
Um ponto de falhaPara monitorar.
Um fornecedorPara governar.

O risco tem tamanho conhecido. Em 77 de cada 100 trocas de plataforma, o prazo estoura. Em 83 de cada 100 migrações de dados, a passagem falha ou custa mais do que o previsto.

A troca em si, para uma operação de médio porte, custa entre 50 mil e 150 mil dólares. E quem migra mal passa a gastar até 40% a mais de manutenção, justamente a conta que a troca prometia diminuir.

A tabela abaixo separa os blocos de custo que você precisa somar antes de decidir. Compare a coluna do sistema único com a coluna das peças separadas, linha por linha.

Bloco de custo Sistema único moderno Peças separadas O que isso significa na sua loja
Mensalidade Concentrada e previsível Uma por peça Cada peça pode custar menos e o total ficar maior
Ligação entre sistemas Baixa, tudo num lugar só Alta e o tempo todo Cada conexão volta na conta todo mês, não é gasto único
A troca em si Não se aplica US$ 50 mil a 150 mil 77 em cada 100 estouram o prazo; 83 em cada 100 migrações de dados falham
Manutenção do dia a dia Previsível Cresce a cada peça nova Quem migra mal gasta até 40% a mais
Velocidade para mudar Lenta, tudo sai junto Rápida, peça por peça O ganho só aparece se houver fila de mudanças segurando venda

A conta honesta quase nunca aprova separar tudo. Ela aprova separar a parte que muda toda semana e manter o resto onde está. Quem soma só a mensalidade e esquece a ligação leva um susto no segundo ano.

Os números de prazo e de orçamento desta seção vêm de Forrester e commercetools, da Bloor e da Gartner, em levantamentos de 2025.

Quando a troca vira dor de cabeça cara?

Vira cara quando você separa partes que já funcionam bem e não tinham fila. O sinal é fácil de ver: oito sistemas, três fornecedores e uma equipe pequena apagando incêndio de conexão. Enquanto isso, a venda e a margem não saem do lugar.

Há três situações em que ficar com o sistema único é a decisão certa. A primeira é volume estável: se a loja aguenta a Black Friday com um reforço pontual, a peça separada resolve um problema que você não tem.

A segunda é conexão já resolvida. Se o sistema atual já entrega produto, preço, estoque e política por API estável, os robôs de compra já conseguem ler a sua loja.

A terceira é equipe pequena. Separar em peças supõe vários times publicando ao mesmo tempo, e uma equipe enxuta cuidando de oito sistemas paga a complexidade sem colher a velocidade.

Três casos em que o monólito vence

  • Seo throughput é estável e os picos de Black Friday são absorvidos com infraestrutura elástica pontual
    entãoa elasticidade granular resolve um problema que você não tem
  • Seo monólito moderno já expõe produto, preço, estoque e política por contrato estável
    entãoa propriedade agent-ready está entregue sem reescrita
  • Sea equipe é enxuta e operaria oito serviços
    entãopaga complexidade sem colher a velocidade que ela existe para entregar

Vale olhar um número que pesa na decisão. Mais de 40% dos projetos de troca de ERP (o sistema que controla estoque, compras e financeiro) são cancelados até 2027. O motivo é o custo. Às vezes é um valor que ninguém soube definir antes de começar. O projeto que começa sem um gargalo com nome vira essa estatística.

O calendário brasileiro encarece o erro. A adequação da nota fiscal eletrônica tem prazo em 3 de agosto de 2026, e a união entre TOTVS e Linx está em curso. Quem escolher esse momento para trocar tudo de uma vez junta dois riscos grandes no mesmo trimestre. O caminho seguro é o contrário: acerte o fiscal primeiro e separe a parte volátil depois.

Para ser achado pelo ChatGPT eu preciso trocar tudo?

Não. O que faz a loja ser lida por um robô de compra é ter endereços estáveis para produto, oferta, estoque, política e carrinho. Um sistema único moderno com boas APIs entrega isso.

O Model Context Protocol, o padrão que deixa um robô usar os seus sistemas com permissão e registro, funciona sobre qualquer sistema que tenha API clara. Para ser comprável por máquina, você organiza a porta de entrada, sem quebrar a loja em pedaços.

Bisturi versus conta de manutenção

Composable mal aplicado

  • Decompõe o catálogo inteiro sem gargalo real
  • Cada contrato de API novo vira conta a pagar no segundo ano
  • Adiciona complexidade sem mover indicador de margem
  • Big bang que congela o roadmap por trimestres

Composable bem aplicado

  • Decompõe só a capacidade que trava receita
  • Mede TCO real, incluindo manutenção e versionamento
  • Migração incremental por capacidade (strangler fig)
  • Mantém a receita correndo durante a transição

O que decidir nesta semana

Essa é uma decisão de caixa antes de ser de tecnologia. As cinco escolhas abaixo separam a mudança que se paga da mudança que só engorda a conta, e cabem numa semana de análise.

  • Dê nome ao gargalo antes de dar nome à tecnologia. Aponte a parte do sistema, busca, preço ou carrinho, cuja fila de mudanças está segurando venda. Sem esse nome e sem esse valor, ainda não há caso para separar nada.
  • Some cinco anos, não a mensalidade do primeiro ano. Junte mensalidade, ligação entre sistemas, a troca em si e a manutenção do dia a dia. Use as faixas de mercado como premissa, e não como exceção.
  • Troque uma peça de cada vez. Migre uma parte, meça o que ela moveu na venda e só depois passe para a próxima. A loja continua vendendo durante toda a transição.
  • Proteja a janela de 2026 e 2027. Não comece a troca no mesmo trimestre do prazo fiscal de 3 de agosto. Acerte o fiscal e o sistema central primeiro, e separe a parte volátil depois.
  • Se você está nas três situações do sistema único, arrume a porta de entrada. Volume estável, conexão pronta e equipe pequena pedem boas APIs em vez de uma reescrita. O ganho com robôs de compra vem da porta de entrada organizada, mesmo com um sistema só.

Olhando para 2027, ter as peças certas abertas deixa de ser vantagem e vira condição para um tipo de venda. Quando os padrões de compra por robô se firmarem, quem quiser ser encontrado e vendido por máquina precisa expor produto e preço por endereço estável.

A lição de 2026 continua valendo. A vantagem vem de ter os endereços certos abertos, com o resto da loja estável e barato de manter. Separar por moda continua sendo a forma mais cara de descobrir que arquitetura é decisão de margem.

Volte à pergunta do começo. A joalheria do cenário resolve o problema dela tirando o preço da fila e deixando o resto onde está. Hoje, escreva num papel qual parte do seu sistema está segurando venda e quanto isso custa por mês. Com esse número na mão, a conversa com o fornecedor muda de lado.

Perguntas frequentes

Compensa quando existe uma capacidade específica cuja fila de mudanças trava receita, geralmente busca, preço ou finalização de compra. O custo de mudar essa peça no sistema único fica alto demais para a velocidade que o negócio exige. Não compensa decompor por moda. Se o fluxo de vendas é estável e a integração já está resolvida por API, separar o catálogo inteiro só soma custo, sem mover a receita.

Depende do que você conta. A licença de uma plataforma composable pode ser menor. Mas o custo total de manter tudo inclui o gasto contínuo de manter, vigiar e atualizar cada contrato de API e cada serviço. Numa loja pequena, esse custo de organizar tudo costuma superar o ganho de flexibilidade. Numa operação grande, com vários times publicando em paralelo, a conta se inverte: a flexibilidade paga a complexidade.

O guia de composable commerce agent-ready trata da tese: por que uma arquitetura modular é a base de uma loja que robôs conseguem ler e operar. Este guia desce um nível. É a régua de decisão de quando migrar, como calcular o custo total de manter tudo e em que ponto separar vira exagero caro no mid-market brasileiro. Um defende a direção; o outro decide o passo.

O preço do big bang

77%dos replatformings estouram o prazo
83%das migrações de dados falham ou estouram orçamento
6xmais frequente o ROI em IA sobre fundação composableMACH Alliance, fevereiro de 2026

Para levar deste guia

  1. A velocidade de resposta ao mercado paga a fatura. A meta do composable é publicar rápido, chegar ao mercado depressa e manter o custo total sob controle. Juntar sistemas separados porque um analista disse que é o futuro só adiciona conta a pagar.

  2. No mid-market brasileiro, composable compensa quando a fila de mudanças em uma capacidade específica (busca, pricing, checkout) trava receita; vira overengineering caro quando se decompõe o catálogo inteiro sem gargalo real.

  3. O custo que estoura no segundo ano é a integração contínua. O custo total de manter tudo (TCO) do composable inclui cada contrato de API novo para manter, monitorar e versionar, além da licença de plataforma.

  4. Roadmap congelado por trimestres é o preço do big bang: 77% dos replatformings estouram o prazo e 83% das migrações de dados falham ou estouram orçamento. A migração incremental por capacidade (strangler fig) é a única forma de manter a receita correndo durante a transição.

  5. Três casos legítimos para não trocar o monólito: throughput estável, integração já resolvida via API e equipe pequena. Nesses cenários, modernizar a borda (APIs e event bus) entrega o ganho agêntico sem o trauma e o custo da reescrita.

De onde vêm os números deste guia?

Cada link abre a publicação de origem, com o nome de quem assina o dado e a data em que ele saiu.

Formações gratuitas do portal de educação de Alexandre Caramaschi, fundador da Brasil GEO.

Leve a decisão para o seu contexto

Este guia dá o mapa. A sua operação dá os números. As calculadoras do portal transformam o argumento em conta feita com os seus dados. A Onclick mostra como um backoffice integrado sustenta essa decisão no dia a dia.

Conteúdo curado por Alexandre Caramaschi, Founder da Brasil GEO, ex-CMO da Semantix (Nasdaq), cofundador da AI Brasil. Parte do portal GEO-Ecommerce, a serviço da operação Onclick.