Onde os dados vivem: a ilusão do 'é só mudar'
"É só mudar um campo." A frase parece inofensiva. Uma das maiores armadilhas em projetos com sistemas complexos. Dado não é solto, não é universal. Dado vive em algum lugar — e quando você não sabe onde, você promete mudança sem entender o impacto.
Muita gente começa olhando a tela. O campo está ali, o valor aparece ali. A tela quase nunca é o lar do dado; é a vitrine. O dado pode nascer em outro sistema, ser replicado por integração, ser processado em batch, estar em banco separado, vir de API externa ou estar em cache. Antes de alterar qualquer informação: origem, armazenamento e ciclo de vida. Todo dado tem um ponto de criação. Pedido nasce no sistema de pedidos; pagamento no gateway; limite de crédito no sistema de crédito. Se você quer alterar um campo, a primeira pergunta é: esse dado nasce aqui? Se não nasce, você pode estar tentando alterar um reflexo.
"Permitir editar manualmente o limite de crédito do cliente na tela do pedido." Esse sistema é dono do limite? Ou o limite vem de fora? Se o limite vem de um sistema financeiro externo, editar na tela do pedido pode criar inconsistência ou ser sobrescrito na próxima sincronização. Mesmo que nasça num sistema, o dado pode estar em vários lugares: banco principal, warehouse, cache, legado. Quando você altera a estrutura, pode precisar mexer em schema, replicação, ETL, relatórios históricos. "Adicionar um campo obrigatório no cadastro." O campo pode estar em dezenas de tabelas, precisar de migração de dados antigos, quebrar relatórios históricos. Adicionar campo não é só adicionar campo; é alterar estrutura.
Todo dado percorre uma jornada: nasce, é processado, replicado, consumido, arquivado. Quando você altera um campo, precisa saber se ele entra em relatório, dispara evento, vai pra parceiros. Uma das maiores armadilhas é o histórico. O que acontece com os dados antigos? Se você muda o formato do campo, os antigos precisam migrar? Relatórios precisam se adaptar? "Alterar o modelo de cobrança de mensal para anual." Como ficam as assinaturas já ativas? Relatórios históricos refletem qual modelo? Às vezes o dado que você vê não é o atual — pode ser última sincronização, snapshot da madrugada, cache de 15 minutos. Pedir "mostrar o valor atualizado na hora" pode exigir nova integração e mudança arquitetural. Alterar estrutura de dado pode quebrar contrato de API. Nada disso aparece na tela.
Antes de mudar qualquer dado: onde ele nasce? Onde é armazenado? Quem consome? Tem histórico, integração, batch, réplica? Quem só documenta escreve: "Alterar campo X." Quem pensa no sistema escreve algo como: "Alteração estrutural no campo X, validando impacto em origem, armazenamento, integrações, histórico e relatórios." A tela mostra; a estrutura sustenta. Entender onde os dados vivem é um dos maiores diferenciais que você pode desenvolver.
No próximo post: batch vs tempo real. Porque "na hora" raramente significa o que parece.
