Arquitetura de software tem um “superpoder” — e um “superproblema”: ela amplifica decisões. Uma escolha errada de modelagem, plataforma, stack ou estratégia de migração não costuma falhar de imediato. Ela vai acumulando custo e complexidade até, um dia, a conta chegar.
E quando chega, surge a frase que mantém projetos vivos além do ponto saudável:
“Não dá pra parar agora. A gente já investiu demais.”
Isso não é só teimosia. É um viés cognitivo com nome e sobrenome: sunk cost fallacy (viés do custo afundado). É quando você continua investindo por causa do que já gastou (tempo, dinheiro, reputação), mesmo que o melhor para o futuro fosse parar ou mudar de rota.
A parte perigosa: em tecnologia, esse viés costuma vir vestido de “estratégia”. E, do lado de fora, parece resiliência. Por dentro, pode ser só o passado sequestrando o futuro.
O que você vai levar deste artigo:
- Como sunk cost aparece em decisões de arquitetura (padrões recorrentes).
- Exemplos reais e contemporâneos (incluindo “volta” de microservices).
- Um framework prático para decidir melhor: métricas, kill criteria, decision journal e exit ramps.
- Um checklist pronto para usar em review de arquitetura e steering committees.
O que é sunk cost (e por que ele engana até gente experiente)
Sunk cost é todo custo irreversível. Já foi. Não volta. Tempo investido, dinheiro gasto, esforço feito, reputação colocada.
A falácia acontece quando esse passado vira argumento para decidir o futuro. O paper clássico sobre o tema descreve justamente essa tendência: quanto maior o investimento prévio, maior a probabilidade de continuar, mesmo quando isso não deveria pesar na decisão racional.
Exemplo cômico que todo mundo provavelmente já passou:
Você começou um filme ruim e já está com 1h10 assistidas. Aí pensa:
“Agora eu vou até o fim, porque já investi muito tempo.”
Só que esse 1h10 não volta. A decisão real é só:
“Eu quero gastar mais 50 minutos com isso… ou fazer outra coisa melhor?”
Arquitetura funciona do mesmo jeito: o custo já afundou. O que importa é o custo e o benefício dos próximos meses, não a história que te trouxe até aqui.
Por que sunk cost é tão comum em arquitetura
Porque arquitetura junta três ingredientes que alimentam o viés:
- Investimentos grandes e visíveis
Meses de squads, orçamento, contratos, iniciativas de “plataforma”. - Feedback lento
Você só descobre a conta real em escala: incidentes, p99, custo de observabilidade, coordenação, onboarding. - Política e reputação
Arquitetura é identidade. Quem defendeu uma direção sente o peso de “voltar atrás”.
O resultado é um ambiente onde “mudar de ideia” parece fraqueza — quando, na prática, mudar de ideia com evidência é maturidade.
Onde sunk cost se esconde: 5 padrões que você provavelmente já viu
1) Sunk Cost Driven Architecture: quando a ferramenta manda no desenho
Martin Fowler deu um nome direto: Sunk Cost Driven Architecture. É quando a empresa compra uma plataforma/ferramenta cara e depois força o uso mesmo quando não é adequado, porque “já pagou”. (martinfowler.com)
Sinais típicos
- A arquitetura “se curva” para caber no produto.
- Customização vira o projeto principal.
- A pergunta não é “isso resolve?”, mas “como fazemos isso caber?”.
Pergunta que desmonta o viés
Se hoje a gente não tivesse comprado isso, escolheria de novo?
2) Microservices por inércia: “agora não dá pra voltar”
O sunk cost moderno aparece quando você entra num ecossistema distribuído (microservices + filas + mesh + observabilidade complexa) e o custo explode, mas a resposta é:
“Já fomos longe demais.”
Só que “voltar” acontece. Uma revisão multivocal identifica casos de switch-back (microservices → monólito) em exemplos como Amazon Prime Video (monitoring service), Segment, InVision e até menções ao Istio control plane.
O ponto não é “monólito é superior”. É: microservices não é evolução inevitável. É ferramenta. E ferramenta pode deixar de valer a pena.
3) “Projeto fundação”: valor só no final
Aqui, o projeto pede investimento pesado antes de entregar qualquer coisa mensurável:
- “Primeiro vamos construir a plataforma.”
- “Depois os times migram.”
- “Depois vem a velocidade.”
Isso cria o terreno perfeito para sunk cost, porque toda crítica vira ameaça ao investimento já feito, e não uma avaliação de valor futuro.
4) Reescrita infinita: PRs e mais PRs, e o valor nunca chega
A reescrita começa para reduzir dívida, mas vira um buraco sem fundo. A justificativa muda de “vamos melhorar o produto” para “não dá para parar agora”.
O problema não é reescrever. É reescrever sem hipótese, métrica, data e caminho incremental.
5) Observabilidade como custo afundado
O time criou um padrão caro (logs demais, cardinalidade alta, tracing exagerado) e segue pagando porque “já instrumentamos tudo”. O argumento é passado, não benefício futuro.
Exemplos reais (e contemporâneos) que deixam o viés óbvio
Exemplo A — “Compramos a suíte corporativa, então precisamos usar”
É exatamente o caso do Fowler: depois do investimento, a organização passa a moldar sistemas para justificar a compra, mesmo quando o custo incremental vira absurdo. (martinfowler.com)
Aprendizado: “estar pago” não torna uma escolha boa. Só torna “doloroso admitir”.
Exemplo B — Consolidar pode ser racional: o caso de redução de custos reportada
Um caso muito citado na indústria foi reportado como uma migração “de volta para monólito” que reduziu custo de infraestrutura em >90% em um contexto associado ao Prime Video/monitoring. (devclass.com)
Aprendizado: distribuir tem custos invisíveis (coordenação, debug, tráfego intermediário, observabilidade, pipelines). Consolidar pode ser otimização — não retrocesso.
O framework prático: como decidir sem deixar sunk cost mandar
A parte mais útil deste artigo é simples: você não combate um viés com boa intenção. Você combate com mecanismos de decisão.
1) Separe explicitamente: custo afundado vs custo incremental
No RFC/ADR, escreva:
- Custo afundado (irreversível): já foi, não volta.
- Custo incremental (decidível): próximos X meses, custo operacional, risco, oportunidade.
Isso “desintoxica” a discussão. O passado vira contexto, não argumento.
2) Troque “plano” por “aposta” (com métrica e janela)
Arquitetura é uma sequência de apostas. Use um formato curto:
Acreditamos que [decisão] melhora [métrica] em [X%] até [data], com custo operacional ≤ [limite].
Sem métrica e data, tudo vira narrativa — e sunk cost prospera em narrativa.
3) Defina kill criteria antes de começar
Kill criteria é o antídoto mais forte contra sunk cost. Exemplos:
- “Se em 8 semanas lead time não cair 15%, pausamos e reavaliamos.”
- “Se custo mensal de observabilidade passar X, congelamos expansão e simplificamos.”
- “Se incidentes p1/p2 aumentarem por 2 ciclos, revertemos o rollout.”
O detalhe é crucial: defina quando ainda há entusiasmo.
4) Sempre tenha uma “exit ramp”
Evite caminhos sem retorno. Construa saídas:
- migração por fatias (Strangler),
- feature flags e dual-run temporário,
- adaptadores e compatibilidade reversível,
- contratos versionados.
Você quer reduzir o custo de mudar de ideia, porque sunk cost cresce quando mudar de ideia é caro.
5) Meça “custo de complexidade” (e não só entrega)
Métricas que expõem o problema:
- MTTD/MTTR,
- hops por request crítico,
- p95/p99 após mudanças,
- custo mensal por fluxo (infra + observabilidade),
- dependências entre domínios/times.
Quando essas métricas pioram e a justificativa é “só mais um pouco”, você está vendo o viés ao vivo.
Checklist: sinais de que sua decisão está sendo guiada por sunk cost
Se marcar 3 ou mais, pare e reavalie:
- “Não dá pra parar porque já investimos muito.”
- O sucesso é descrito em narrativa, não em métrica.
- Estamos moldando arquitetura para caber numa ferramenta comprada. (martinfowler.com)
- A alternativa “desfazer” virou tabu.
- O custo operacional cresce e ninguém sabe explicar por quê.
- O roadmap virou “plataforma primeiro, valor depois”.
- “Ponto de não retorno” virou argumento, não risco.
Como aplicar amanhã no seu time
Se você quiser algo prático mesmo que funciona para revisar uma iniciativa grande (migração, reescrita, plataforma, microservices):
- Abra um doc e escreva duas colunas:
- Custo afundado (irreversível)
- Custo incremental (próximos 90 dias)
- Escreva a aposta em 3 linhas:
- o que melhora, quanto, até quando.
- Defina 2–3 métricas de sucesso e 2–3 de “custo de complexidade”.
- Defina kill criteria (antes de discutir “como fazer”).
- Desenhe uma exit ramp: como pausar/reverter sem quebrar tudo?
- Agende uma review em 6–8 semanas com base só nas métricas.
Nada de “sensação”. Nada de “narrativa”.
Esse processo reduz o poder do “já investimos demais” porque muda a pergunta para:
“Qual decisão maximiza valor daqui pra frente?”
Conclusão
Sunk cost é um viés simples, mas devastador em arquitetura: ele sustenta plataformas que ninguém quer, reescritas infinitas e estratégias distribuídas que viram um labirinto.
O antídoto não é “ter coragem”. É criar decisões que suportem mudança:
- separar passado e futuro,
- tratar arquitetura como aposta verificável,
- definir kill criteria,
- desenhar exit ramps,
- medir custo de complexidade,
- manter um decision journal.
Se você faz isso, mudar de ideia deixa de ser “fracasso” e vira o que deveria ser: engenharia.
Referências e leituras recomendadas
- Arkes & Blumer (1985), The Psychology of Sunk Cost — base experimental e descrição do efeito. (sciencedirect.com)
- Martin Fowler — Sunk Cost Driven Architecture — como o viés aparece em decisões de plataforma/ferramenta. (martinfowler.com)
- Su et al. (2024) — revisão multivocal sobre switch-back microservices → monólito (Prime Video, Segment, InVision, Istio). (mdpi.com)
- Cobertura do caso de redução de custos via consolidação (contexto Prime Video/monitoring). (devclass.com)
