Quando um produto muda, a forma como ele representa os dados também pode mudar: um campo é renomeado, uma entidade é dividida ou uma nova regra de negócio é introduzida. A decisão não é apenas técnica. É preciso escolher entre atualizar os registros existentes, adaptar os dados sempre que forem consultados ou manter os dois formatos durante uma transição.
A pergunta útil é quando migrar dados e quando transformá-los na leitura. A resposta depende de quem consome as informações, do nível de consistência de que o produto precisa e do custo de manutenção da solução. Nenhuma abordagem é universalmente melhor: o objetivo é explicitar as concessões envolvidas e definir como verificar se elas funcionam.
O que muda em cada abordagem
Uma migração persistente modifica os dados armazenados para que sigam o novo modelo. Ela pode ser executada em uma operação controlada ou em lotes, conforme o volume, a infraestrutura e os requisitos de disponibilidade. Depois, as consultas trabalham com a nova representação, embora, durante a transição, talvez precisem reconhecer registros antigos.
A transformação na leitura mantém os dados originais e os adapta no momento de devolvê-los. Uma camada de acesso, um serviço ou uma consulta pode converter o formato antigo na estrutura esperada pelo consumidor atual. É uma forma de compatibilidade que evita uma alteração em massa imediata, mas acrescenta trabalho às leituras e lógica que alguém terá de manter.
Também há uma opção intermediária: manter temporariamente os dois formatos e migrar aos poucos. Por exemplo, a aplicação pode ler o formato novo e, se ele não existir, converter o antigo; as novas gravações já salvam os dados no formato atualizado. Essa estratégia exige regras claras para evitar que cada consumidor implemente sua própria variação.
Critérios para escolher
Antes de decidir, descreva a mudança como uma necessidade observável: quais dados mudam, quem os utiliza e qual comportamento deve ser mantido. Em seguida, avalie estes critérios:
- Consistência: se todos os consumidores precisam ver o mesmo valor e seguir as mesmas regras, uma representação persistente comum pode reduzir divergências. Se a conversão for específica de uma interface ou de um consumidor, uma camada de leitura pode ser mais adequada.
- Frequência e custo de leitura: uma transformação repetida em um fluxo muito utilizado pode aumentar a latência e o consumo de recursos. Se as leituras forem pouco frequentes ou o conjunto de dados for pequeno, esse custo talvez seja aceitável; avalie-o no contexto real.
- Volume e operação: uma migração completa pode exigir tempo, controle de erros e capacidade para processar registros sem interromper o serviço. Para grandes volumes, considere lotes e acompanhamento do progresso, em vez de presumir que uma única operação será segura.
- Número de consumidores: com vários serviços, aplicativos, relatórios ou integrações, alterar o armazenamento pode gerar efeitos em cadeia. Identifique quem depende do esquema e se todos podem ser atualizados de forma coordenada.
- Reversibilidade: transformar na leitura preserva os dados de origem, o que pode facilitar a retomada do comportamento anterior. Uma migração destrutiva exige um backup ou um mecanismo de recuperação testado, além de um plano para as alterações feitas depois.
- Regras de negócio: se a conversão depender de decisões que podem mudar, manter os dados originais permite reavaliá-la. Se a nova forma representar um fato estável e necessário para todos, persistir essa representação pode simplificar o sistema.
Não compare apenas o custo de executar a migração com o de criar um adaptador. Inclua os custos recorrentes: consultas mais complexas, observabilidade, testes, suporte a versões antigas e remoção futura da compatibilidade.
Sinais de que vale a pena migrar
Uma migração persistente costuma ser mais atraente quando o novo modelo será a representação principal por um longo período, muitos consumidores precisam da mesma transformação ou o trabalho de adaptação afeta a latência de forma mensurável. Ela também pode ser preferível quando a lógica de leitura se espalhou por vários lugares e já não há uma única definição confiável.
Por outro lado, a transformação na leitura pode ser razoável se a mudança for temporária, o formato antigo precisar ser preservado, houver poucos consumidores controlados ou as regras do novo modelo ainda estiverem sendo validadas. Também pode ajudar quando o custo ou o risco de gravar em massa em produção supera o benefício imediato, desde que o desempenho seja aceitável e a compatibilidade tenha limites claros.
Há sinais de que uma solução temporária está se tornando dívida técnica: condições para cada versão histórica, consultas que misturam formatos sem uma regra comum, erros diferentes entre consumidores e testes que não cobrem todas as variações. Se isso acontecer, não basta acrescentar mais um caso. É preciso decidir qual formato será canônico e estabelecer uma data ou condição verificável para descontinuar os anteriores.
Como fazer uma transição gradual
Uma migração gradual reduz o risco ao separar a implantação da aplicação do processamento de todos os registros. Um plano prático pode seguir estas etapas:
- Inventarie as dependências. Localize produtores, consumidores, tarefas agendadas, relatórios e contratos de integração que usam o modelo afetado. Esclareça quem é responsável por cada um.
- Defina a compatibilidade. Documente quais formatos são aceitos, qual é a fonte de verdade e o que deve acontecer quando faltar um campo ou surgir um valor inesperado. Evite inferências silenciosas que ocultem dados inválidos.
- Implante leitores compatíveis. Garanta que a aplicação consiga lidar com dados antigos e novos antes de começar a gravar no novo formato. Assim, uma versão anterior não falhará ao encontrar registros atualizados.
- Altere as gravações. Faça com que as novas operações produzam o formato desejado. Se duas representações forem gravadas durante um período, defina qual delas prevalece e como as divergências serão detectadas.
- Processe os dados existentes. Execute a migração de forma controlada, registrando o progresso e os erros. Use lotes adequados ao sistema e planeje a operação para que possa ser retomada sem duplicar efeitos.
- Remova a compatibilidade. Elimine a leitura do formato antigo somente quando as métricas e verificações indicarem que não há mais consumidores nem registros que dependam dele.
A sequência exata pode variar. Em sistemas com requisitos rigorosos de disponibilidade, as etapas de leitura e gravação costumam ser implantadas de forma compatível antes de os dados serem alterados. A decisão deve levar em conta o comportamento das versões antigas que talvez continuem ativas durante uma implantação.
Valide os resultados e prepare a reversão
Antes de migrar tudo, teste a conversão com dados representativos e compare os resultados. Verifique contagens, campos obrigatórios, valores extremos, relações entre entidades e regras de negócio. Uma contagem igual, por si só, não comprova que a transformação está correta: compare também valores e comportamentos em casos relevantes.
Se possível, comece com uma comparação que não altere o resultado recebido pelo usuário. Registre as diferenças entre as representações antiga e nova, classifique as divergências e estabeleça limites de aceitação antes de ampliar o processo. Monitore erros, latência e carga durante a operação e deixe claro quem pode decidir interrompê-la.
A reversão deve considerar as gravações feitas depois da mudança. Restaurar um backup anterior pode eliminar atualizações válidas; por isso, determine se é possível voltar ao leitor antigo sem reverter os dados ou se será preciso reconciliar as alterações. Teste esse caminho antes de depender dele.
Lista de verificação para decidir
- O formato canônico e a fonte de verdade estão identificados?
- Quantos consumidores dependem do esquema e quem controla cada um?
- O impacto da transformação na leitura sobre a latência e os recursos foi medido?
- A lógica temporária está centralizada, testada e tem critérios para ser removida?
- A migração pode ser pausada e retomada, e consegue detectar registros com falha?
- Foram definidos comparações, limites de aceitação e responsáveis pela validação dos resultados?
- Existe uma reversão segura que considere as novas gravações?
Escolha a transformação na leitura quando a compatibilidade tiver escopo limitado, for reversível e puder ser mantida operacionalmente. Escolha a migração quando o novo modelo precisar ser comum e persistente, for mais simples de consumir e houver um plano seguro para atualizar os dados. Se ainda houver incerteza, adote uma transição temporária com métricas, responsável e critério de saída: adiar uma migração pode ser uma decisão válida; adiá-la sem prazo nem controle torna a compatibilidade permanente.