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.
Alexandre Caramaschi
Founder da Brasil GEO, ex-CMO da Semantix (Nasdaq), cofundador da AI Brasil
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
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
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
- Busca e merchandisingOnde mora a descoberta.
- Pricing e promoçãoOnde mora a margem.
- Checkout, por últimoOnde mora a conversão e o maior risco de mexer.
- 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
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 pontualentã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ávelentãoa propriedade agent-ready está entregue sem reescrita
- Sea equipe é enxuta e operaria oito serviçosentã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
Quando composable commerce compensa para uma operação de mid-market no Brasil?
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.
Composable é mais caro ou mais barato que um monólito?
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.
Qual a diferença entre este guia e o guia de arquitetura agent-ready?
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
Para levar deste guia
-
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.
-
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.
-
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.
-
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.
-
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.
- Model Context Protocol, especificação do protocolo.
- Curadoria Brasil GEO, Alexandre Caramaschi, 2026.
Cursos para aprofundar
Formações gratuitas do portal de educação de Alexandre Caramaschi, fundador da Brasil GEO.
API Design REST e GraphQL
Contratos bem desenhados com OpenAPI, versionamento e rate limit para integrar sistemas sem acoplamento frágil.
Curso gratuitoAutomação com n8n e Make
Workflows com n8n e Make, webhooks e filas para conectar ERP, CRM e loja sem depender de fila de engenharia.
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.