Dono do dado: o princípio invisível que separa sistemas saudáveis de caos silencioso
Cena clássica: o cliente liga dizendo que o pedido está "Cancelado" na tela A — na tela B aparece "Em andamento". O relatório financeiro mostra outro status, o dashboard outro. Alguém pergunta: "Qual é o status correto?" Silêncio. O problema quase nunca começa na falha; começa quando ninguém definiu: quem é o dono desse dado?
O dono é o sistema que tem autoridade pra criar, alterar e definir a versão oficial daquela informação. Pedido: sistema de pedidos. Pagamento: sistema de pagamento. Parece óbvio — na prática não é. O caos começa quando vários sistemas armazenam e alteram a mesma informação. Requisito: "Permitir alterar o status do pedido direto na tela de atendimento." Essa tela é de qual sistema? Esse sistema é dono do status? Se a tela não for dona do dado, você abriu porta pra inconsistência.
Quando dois sistemas podem alterar o mesmo dado: A diz "Cancelado", B diz "Aprovado". Qual vale? Dois sistemas atualizam quase ao mesmo tempo — qual prevalece? Quando os dados divergem, as pessoas param de confiar; surgem planilhas paralelas. O BA escreve requisitos que permitem ou bloqueiam comportamentos. Permitir alteração num sistema que não é dono daquele dado é criar risco arquitetural. A pergunta certa não é "podemos permitir?"; é "esse sistema é a fonte da verdade desse status?" Se não for, a alteração tem que acontecer no sistema dono — e os outros refletem, não competem.
Um sistema pode guardar uma cópia do dado sem ser dono. O sistema de pedidos pode guardar o valor pago — mas o dono da transação financeira é o sistema de pagamento. Às vezes sistemas replicam dados pra facilitar consulta. O problema é quando a réplica vira editável ou "quase oficial". Aí a linha entre cópia e autoridade some.
Marketplace e valor do pedido
Pedido no sistema A, pagamento no B, entrega no C. Requisito: "Permitir alterar o valor do pedido após confirmação." O valor alterado reflete no pagamento? Impacta comissão do seller? Nota fiscal? Se o sistema de pedidos altera o valor sem falar com pagamento e contabilidade, você cria distorção financeira. Em microserviços cada serviço deve ser dono do próprio banco. Se um serviço precisa de informação de outro, consulta ou recebe evento; não altera direto. Relatórios agregam várias fontes; se duas fontes têm versões diferentes do mesmo dado, o relatório vira campo de batalha.
Antes de permitir alteração em qualquer tela: "Esse sistema tem autoridade pra alterar essa informação?" Se a resposta for "não sei", você já achou um risco. Pra cada dado crítico existe uma fonte única da verdade. Outros podem consumir, replicar, exibir — não devem competir por autoridade. Em vez de "Permitir alterar o status na tela X", algo como: "Alteração de status deve ser feita no sistema Y (fonte da verdade), com propagação pros demais consumidores."
Governança de dados começa no requisito, na pergunta certa. Permitir alteração em qualquer lugar pode parecer agilidade e ser o começo do caos.
No próximo post: onde os dados vivem. Porque achar que dado é universal é uma das maiores ilusões em projeto.
