← Todos os Posts

O custo 15x de uma decisão ruim de banco de dados: lições sobre o momento certo de decidir

5 min read

Medi o custo de uma decisão de banco de dados em três sistemas de produção. O custo de migração cresceu 15x ao longo de três anos de dados acumulados e dependências de schema.

TL;DR

A maioria dos engenheiros inverte o timing das decisões: deliberam por dias sobre escolhas reversíveis (qual biblioteca de cliente API usar) e tomam decisões irreversíveis em minutos (schema de banco de dados durante o planejamento de sprint). Ray Dalio e Jeff Bezos descrevem o mesmo framework por ângulos diferentes: decisões reversíveis devem acontecer rápido porque o atraso custa mais do que a imperfeição. Decisões irreversíveis merecem análise proporcional ao que está em jogo. Aprendi isso da maneira difícil em três sistemas onde atalhos iniciais de schema se acumularam em custos de migração de seis dígitos.

A migração que me ensinou

No meu primeiro ano na ZipRecruiter, herdei um sistema onde a equipe original havia escolhido um schema desnormalizado para acelerar o desenvolvimento inicial. A decisão fazia sentido na época: entregar rápido, normalizar depois. O “depois” nunca veio.

No segundo ano, três serviços dependiam da estrutura desnormalizada. No terceiro ano, o schema havia acumulado 14 meses de dados de produção, relacionamentos de chave estrangeira que presumiam o layout desnormalizado e seis consultas de relatório que quebrariam com qualquer mudança estrutural.

O custo da migração no primeiro mês teria sido aproximadamente dois dias de engenharia. No décimo segundo mês, duas semanas. No trigésimo sexto mês, a estimativa era de três meses de tempo dedicado de engenharia, mais um deployment gradual com lógica de dual-write para evitar downtime. Esse é o multiplicador de 15x: não porque o problema ficou mais difícil, mas porque o raio de impacto se expandiu a cada mês de dependências acumuladas.1

O framework

Decisões reversíveis: decida em minutos

Escolher um framework de frontend para um protótipo. Definir uma convenção de nomenclatura de variáveis. Selecionar uma região de cloud para staging. Escolher qual post de blog escrever primeiro.

Essas decisões compartilham um traço: mudar de direção custa aproximadamente o mesmo independentemente de quando você muda. Adiar desperdiça tempo sem melhorar o resultado.2

Meu teste: Se consigo desfazer essa decisão na semana que vem com menos de um dia de trabalho, decido agora.

Quando construí este site, escolhi HTMX em vez de React em cerca de dez minutos. Se HTMX tivesse sido a escolha errada, trocar de framework em um site pessoal com templates renderizados no servidor teria levado um fim de semana. O baixo custo de reversão significava que velocidade importava mais do que análise.

Decisões irreversíveis: decida em dias

Escolher um engine de banco de dados para dados de clientes. Definir um contrato de API do qual sistemas externos dependem. Selecionar uma arquitetura de hooks sobre a qual 86 hooks serão construídos.

Essas decisões se acumulam. O custo de reversão cresce ao longo do tempo, frequentemente de forma exponencial.3

Meu teste: Se o custo de desfazer essa decisão dobra a cada seis meses, invisto análise proporcional ao que está em jogo.

Minha arquitetura de hooks em .claude/ é um exemplo de decisão irreversível feita corretamente. Passei duas semanas projetando o modelo de ciclo de vida dos hooks (PreToolUse, PostToolUse, Stop e outros três) antes de escrever um único hook. Esse design agora suporta 86 hooks cobrindo segurança de git, controle de recursão, aplicação de filosofia, gates de qualidade e observabilidade. Mudar o modelo de ciclo de vida neste ponto exigiria reescrever cada hook. A análise antecipada se pagou muitas vezes.4

Cinco decisões que acertei e errei

Acerto: escolher CSS puro em vez de Tailwind

Tipo: Reversível. Tempo gasto: 20 minutos.

Escolhi CSS puro com custom properties em vez de Tailwind para este site. Se estivesse errado, poderia migrar para Tailwind em um fim de semana. A decisão levou 20 minutos: eu valorizava aprender os fundamentos de CSS mais do que a produtividade de um framework. Dois anos depois, fico feliz por ter escolhido CSS puro porque cada otimização (alcançar pontuação perfeita no Lighthouse) exigia entender o que o CSS realmente fazia. Mas a decisão poderia ter ido para qualquer lado sem consequências.

Acerto: investir no design da arquitetura de hooks

Tipo: Irreversível. Tempo gasto: Duas semanas.

86 hooks agora dependem do modelo de ciclo de vida. Valeu cada hora de design antecipado.

Erro: apressar o schema de conteúdo do blog

Tipo: Irreversível. Tempo gasto: 30 minutos.

Defini o dataclass ContentMeta do blog post em uma única sessão: title, slug, date, description, tags, author, published. Não incluí category, series, hero_image, scripts ou styles. Cada adição posterior exigiu modificar o parser, atualizar cada template que consumia os metadados e re-testar todo o pipeline do blog. Cinco adições ao longo de três meses custaram mais tempo total do que projetar o schema cuidadosamente desde o início teria custado.

Erro: deliberar sobre a ordem dos posts do blog

Tipo: Reversível. Tempo gasto: Duas horas em uma sessão de planejamento.

Passei duas horas decidindo quais posts de blog escrever primeiro. A ordem era completamente reversível. Eu deveria ter começado a escrever qualquer coisa e reordenado depois com base no que aprendesse.

Acerto: design cuidadoso dos limites de consenso

Tipo: Irreversível. Tempo gasto: Uma semana.

Meu sistema de deliberação usa limites de consenso adaptativos por tarefa: 85% para decisões de segurança, 80% para funcionalidades, 65% para refatoração, 50% para documentação. Errar nesses limites bloquearia trabalho legítimo (limites altos demais) ou aprovaria mudanças perigosas (limites baixos demais). Testei cada limite contra históricos de tarefas reais antes de confirmar.

A inversão comum

Engenheiros passam dias escolhendo bibliotecas de cliente API (reversível, baixo custo de troca) enquanto projetam schemas de banco de dados em reuniões de planejamento de sprint (irreversível, alto custo de migração).

Gestores fazem o mesmo: semanas avaliando ferramentas de gerenciamento de projetos (reversível) enquanto reestruturam equipes da noite para o dia (irreversível, alto custo humano).5

A inversão acontece porque decisões reversíveis parecem importantes no momento (a equipe pode julgar minha escolha de biblioteca) enquanto decisões irreversíveis parecem abstratas (a migração é daqui a três anos). As sensações estão exatamente erradas.

Duas perguntas antes de cada decisão

  1. Quanto custa reverter em seis meses? Se a resposta é “trivial”, decida agora.
  2. O atraso melhora a informação disponível? Se nenhum dado novo surgirá da espera, decida agora.

Só delibere quando ambas as condições favorecem esperar: a reversão é cara e informações melhores surgirão com o tempo.6 Todo o resto é decidido imediatamente.

Principais conclusões

Para engenheiros: - Escolhas de stack tecnológico para protótipos são reversíveis; faça-as em minutos, não em reuniões - Schemas de banco de dados e contratos de API são irreversíveis em escala; invista análise antecipada proporcional a quantos sistemas dependerão da decisão - Rastreie os custos das suas decisões; medir o multiplicador de 15x na migração mudou como eu avalio investimento antecipado

Para gestores: - Mudanças de ferramentas e processos geralmente são reversíveis; faça pilotos rápidos e itere - Decisões de estrutura de equipe e contratação têm alto custo de reversão; delibere proporcionalmente - Quando uma equipe passa uma semana escolhendo uma biblioteca, pergunte se o custo de reversão justifica o tempo de deliberação

Referências

  1. Author’s analysis of database migration costs across three production systems at ZipRecruiter. Migration cost grew 15x over three years of accumulated data and schema dependencies. ↩

  2. Bezos, Jeff, “2015 Letter to Shareholders,” Amazon, 2016. “Type 1 and Type 2 decisions” framework. ↩

  3. Dalio, Ray, Principles: Life and Work, Simon & Schuster, 2017. Core framework on decision-making timing and radical transparency. ↩

  4. Author’s hook architecture design process. 86 hooks across 6 lifecycle points, documented in “Claude Code hooks”. ↩

  5. Kahneman, Daniel, Thinking, Fast and Slow, Farrar, Straus and Giroux, 2011. Research on decision fatigue and cognitive bias. ↩

  6. Taleb, Nassim Nicholas, Antifragile, Random House, 2012. Framework for optionality and decision-making under uncertainty. ↩