Como Evoluir Schema Sem Derrubar Produção

O problema

Tem time que trata mudança de schema assim:

1. altera a tabela
2. sobe o código novo
3. torce

As vezes passa.

As vezes produz exatamente o tipo de incidente chato que parece bobo em retrospecto:

• app antiga lendo coluna que sumiu
• app nova esperando dado que ainda não existe
• rollback impossivel
• dado escrito em formato misto

Schema em produção quebra menos por SQL errado e mais por coordenação ruim.

Modelo mental

Pense assim:

evoluir schema e um problema de compatibilidade temporal

O dado não muda sozinho.

Durante um tempo, coexistem:

• versão antiga do código
• versão nova do código
• dado velho
• dado novo

Se o seu plano não funciona nesse período de convivio, ele ainda esta incompleto.

Quebrando o problema

Primeiro expanda sem quebrar

O passo mais seguro costuma ser adicionar sem remover:

• nova coluna
• novo campo opcional
• nova tabela de apoio

Esse tipo de mudança tende a ser mais compativel com código que ainda não foi atualizado.

Depois faca a aplicação escrever no formato novo

Só adicionar coluna não muda o comportamento.

Você precisa decidir:

• quando começar a gravar no lugar novo
• se vai escrever em dois lugares por um tempo
• como ler durante a transição

Aqui mora boa parte da engenharia.

Migre leitura com cuidado

Leitura costuma ser o ponto mais traicoeiro.

Se o sistema passa a depender exclusivamente do formato novo cedo demais, qualquer dado antigo vira bug.

Por isso e comum:

• ler do novo quando existir
• cair para o velho enquanto a migração acontece

Essa fase parece feia.

Mas geralmente e a feiura correta.

Só remova no fim

Apagar coluna, constraint ou caminho antigo cedo demais e o jeito clássico de transformar rollout em incidente.

Remoção costuma vir por ultimo, depois que:

• escrita nova esta estavel
• leitura nova esta consolidada
• dado antigo foi migrado
• rollback já não depende do formato anterior

Exemplo simples

Imagine que users tem uma coluna full_name e o time quer separar em:

• first_name
• last_name

Plano ruim:

1. remove full_name
2. adiciona as novas colunas
3. sobe a aplicação nova

Plano melhor:

1. adiciona first_name e last_name
2. aplicação passa a escrever nos campos novos sem parar de suportar o antigo
3. job migra dados existentes
4. leitura passa a preferir campos novos
5. só no fim full_name deixa de ser necessário

Esse plano parece mais longo.

Na prática, costuma ser bem menos dramatico.

Erros comuns

• Fazer migration destrutiva cedo demais.
• Assumir deploy perfeitamente sincronizado entre todas as instancias.
• Esquecer rollback na hora de mudar o formato de dado.
• Tratar schema como detalhe de banco e não como contrato vivo com a aplicação.
• Mudar leitura e escrita ao mesmo tempo sem fase de transição.

Como um senior pensa

Quem tem mais experiência costuma fazer esta pergunta antes de alterar schema:

“Durante a transição, o que acontece se metade do tráfego estiver no código novo e metade no antigo?”

Se a resposta for “quebra”, o plano ainda esta imaturo.

Senioridade aqui aparece muito mais na orquestração da mudança do que no comando SQL em si.

O que o entrevistador quer ver

Em entrevista, esse tema mede maturidade operacional e de sistema.

O avaliador quer ver se você:

• pensa em compatibilidade temporária
• evita migration destrutiva como primeiro passo
• entende leitura e escrita como partes separadas da transição
• considera rollout e rollback junto com schema

Uma resposta forte costuma soar assim:

“Eu evitaria uma migration que quebra o formato antigo de uma vez. Primeiro expandiria o schema, depois faria a aplicação conviver com velho e novo por um tempo, migraria dados e só no fim removeria o caminho antigo.”

Mudar schema com segurança e mais sobre coreografar convivio do que sobre escrever SQL bonito.

O sistema não quebra quando o schema muda. Ele quebra quando as versões param de conversar.