Como evitar que duas pessoas sobrescrevam a mesma edição em um sistema

O que você vai levar deste guia

• Envie a versão que foi lida junto com a intenção de alteração.
• Compare a versão e grave a mudança como uma operação indivisível.
• Preserve o rascunho e mostre as diferenças quando ocorrer conflito.

Reproduza a perda com duas sessões reais de teste

Abra o mesmo registro em duas sessões de um ambiente de teste. Na primeira, altere um campo e salve. Na segunda, que ainda contém o estado antigo, altere outro campo e salve. Consulte o resultado novamente. Se a primeira mudança desaparece, o sistema provavelmente está aceitando uma representação antiga como se ainda fosse atual. Esse roteiro simples torna visível um defeito que costuma ser confundido com desatenção do usuário, porque cada pessoa recebeu uma confirmação de sucesso.

No exemplo fictício da empresa Projeto Vale, duas coordenadoras editam o plano de uma instalação. Uma muda a data prevista e a outra ajusta o responsável. O formulário envia todos os campos, incluindo aqueles que não foram alterados na segunda sessão. Ao salvar, a data antiga volta sem qualquer aviso. O problema não é que as pessoas trabalharam ao mesmo tempo; é que a aplicação não registrou sobre qual versão cada decisão foi tomada.

Guarde o roteiro e os valores antes, entre e depois dos salvamentos. Inclua uma variante em que ambas alteram o mesmo campo e outra em que uma delas exclui o registro. Esses casos terão respostas diferentes. O objetivo inicial é escrever a garantia que falta: uma alteração baseada em versão antiga não pode substituir silenciosamente uma mudança confirmada. A forma de resolver a colisão virá depois, com critérios ligados ao tipo de informação.

Defina o que representa uma versão do recurso

Uma versão deve mudar quando o estado relevante para a edição muda. Pode ser um contador controlado pelo servidor ou um identificador adequado à representação, desde que o contrato seja consistente. Não peça ao navegador que invente o próximo número como prova de atualidade. O cliente informa qual versão observou; o servidor decide se ela ainda corresponde ao estado que será alterado. Identidade do registro e versão são informações diferentes e precisam permanecer distintas.

Determine a abrangência. O plano fictício inclui data, equipe e instruções operacionais. Se esses campos são apresentados e validados juntos, uma versão do plano inteiro pode ser um começo compreensível. Se há comentários independentes adicionados por várias pessoas, talvez eles sejam recursos próprios e não precisem invalidar toda edição do plano. Essa decisão evita conflitos desnecessários sem abandonar a proteção das regras que dependem de vários campos.

Uma marca de horário pode parecer suficiente, mas exige cuidado com resolução, atualizações no mesmo instante e origem do relógio. Escolha uma estratégia cuja comparação seja confiável no armazenamento utilizado. A versão também não deve expor dados privados nem carregar uma regra de autorização implícita. Saber uma versão atual não dá permissão para editar; a pessoa precisa estar autorizada e a mudança precisa ser válida independentemente da verificação de concorrência.

Inclua a condição de atualização no contrato da API

Ao ler o registro, devolva sua versão. Ao solicitar alteração, o cliente deve apresentar a versão esperada de uma forma documentada. No contrato HTTP, o cabeçalho If-Match descrito pela MDN permite condicionar uma operação à correspondência de um ETag; quando a condição falha, a resposta é 412. Essa é uma opção para expressar a precondição. A implementação ainda precisa garantir a comparação correta junto da gravação.

Defina o comportamento quando o cliente não envia a versão. Aceitar silenciosamente uma atualização incondicional deixa uma porta para integrações ou telas antigas contornarem a proteção. Planeje a compatibilidade: identificar consumidores, comunicar o contrato e migrá-los antes de tornar a condição obrigatória pode ser necessário. Durante a transição, registre quais caminhos continuam sem proteção e não declare o problema resolvido em toda a aplicação enquanto eles puderem sobrescrever os mesmos dados.

A resposta de sucesso deve devolver o estado confirmado ou uma forma clara de obtê-lo, incluindo a nova versão. Não mantenha o formulário exibindo a versão antiga após salvar. Uma segunda alteração legítima na mesma tela precisa usar a referência atualizada. Também trate gravações que normalizam valores no servidor: se a aplicação ajusta formato ou calcula campos, a interface deve refletir o resultado real, não apenas presumir que o rascunho enviado se tornou o estado final.

Compare e atualize sem abrir outra janela de corrida

Uma sequência de ler versão, comparar na aplicação e depois gravar pode falhar sob concorrência. Duas solicitações podem ler a mesma versão, ambas considerar a condição válida e ambas atualizar. A proteção precisa estar no ponto de confirmação, usando uma operação condicional ou uma transação e mecanismo adequados ao banco. O resultado da gravação deve permitir distinguir atualização realizada de condição que já não correspondia, sem tratar ausência de alteração como sucesso.

No exemplo fictício, a atualização do plano exige que o identificador corresponda e que a versão continue sendo a observada pela coordenadora. Ao confirmar a alteração, o armazenamento também avança a versão. Se outra mudança chegou primeiro, a segunda tentativa não modifica o registro. A aplicação então consulta ou apresenta informações necessárias à resolução, respeitando as permissões da pessoa. O detalhe do comando depende da tecnologia, mas a garantia não pode depender apenas da velocidade entre duas chamadas.

Inclua todas as mudanças relevantes na mesma disciplina. Uma rotina automática que altera a data sem avançar a versão pode tornar o controle incompleto. O mesmo vale para importações, tarefas administrativas e scripts de manutenção. Faça um inventário dos escritores do recurso e teste os caminhos principais. Uma proteção presente somente no formulário mais usado deixa perdas intermitentes difíceis de explicar quando outro processo modifica o registro ao mesmo tempo.

Preserve o rascunho quando a versão ficou antiga

Ao detectar conflito, mantenha o que a pessoa digitou e explique que o registro mudou desde a abertura. Evite apenas recarregar a página, porque isso transforma a proteção contra sobrescrita em perda local de trabalho. Apresente a versão atual e permita comparar com o rascunho. Para campos extensos, uma diferença textual pode ser útil; para data, responsável e status, uma comparação direta costuma ser mais clara que um bloco técnico de alterações.

Na Projeto Vale fictícia, a segunda coordenadora deve ver que a data foi atualizada enquanto ela alterava o responsável. Pode então confirmar uma nova edição sobre a versão atual, preservando a data e aplicando a troca de pessoa, se as regras permitirem. A interface não precisa expor o termo ETag. Precisa explicar a consequência e oferecer uma ação segura: revisar alterações, copiar o rascunho ou desistir. A nova submissão deve usar a versão que foi efetivamente revisada.

Evite botões genéricos de “forçar” sem limites. Se o negócio realmente precisa substituir o estado atual, isso deve ser uma operação explícita com autorização, confirmação e histórico apropriados. Não esconda uma atualização incondicional atrás de uma mensagem de conflito. Uma pessoa pode querer insistir porque não entendeu a diferença, e o sistema deve ajudá-la a tomar a decisão informada em vez de oferecer a perda silenciosa como atalho.

Decida quando combinar mudanças é permitido

Alterações em campos diferentes nem sempre são independentes. A data e a equipe podem estar ligadas à disponibilidade; o limite de horas e o escopo podem determinar uma validação conjunta. Portanto, combinar automaticamente todos os campos não sobrepostos pode produzir um estado que nenhuma pessoa avaliou. Identifique grupos de regras antes de implementar uma mesclagem. Quando a combinação muda a elegibilidade, execute novamente as validações sobre o resultado proposto.

Um modelo de comparação em três estados ajuda a raciocinar: original lido, rascunho local e estado atual. Se um campo mudou apenas no rascunho, pode ser candidato a reaplicação. Se mudou dos dois lados, exige uma decisão específica. Porém essa classificação é só o começo; dependências entre campos ainda precisam ser consideradas. Para instruções textuais, juntar frases automaticamente pode alterar o sentido, mesmo que uma ferramenta de diferenças não encontre linhas sobrepostas.

Escolha uma política proporcional ao uso. Para formulários pequenos e críticos, pedir revisão pode ser mais simples e previsível. Para colaboração intensa em texto, pode ser necessário um mecanismo especializado que mantenha operações de edição. Não transforme todo cadastro em um editor colaborativo complexo sem evidência de necessidade. A Tironi Tech pode analisar frequência de colisões e relações entre campos para desenvolver uma resolução compatível com a rotina, evitando tanto perdas quanto interrupções desnecessárias.

Diferencie conflito de versão, validação e acesso

O usuário precisa entender por que a mudança não foi concluída. Versão antiga significa que o contexto mudou. Validação de negócio significa que a combinação proposta não atende a uma regra. Falta de permissão significa que a pessoa não pode executar a operação. Misturar essas situações em “erro ao salvar” cria reenvios inúteis e chamados sem informação. Estruture respostas que permitam à interface oferecer a ação adequada sem revelar dados que a pessoa não tem direito de consultar.

Considere que o acesso pode mudar enquanto o formulário está aberto. Se a coordenadora deixa de poder ver o plano, a resposta de conflito não deve devolver o conteúdo atualizado só para ajudar a comparar. A autorização continua sendo verificada. Da mesma forma, se o registro foi removido, o sistema deve distinguir a ausência do recurso de uma atualização que chegou antes. O rascunho pode ser preservado localmente conforme as regras do produto, mas isso não autoriza recriar automaticamente o objeto apagado.

Registre as ocorrências com informações úteis: recurso, versão esperada, resultado e caminho de edição, evitando armazenar o formulário inteiro sem necessidade. A quantidade de conflitos pode orientar melhorias de processo ou de interface. Muitos conflitos em um campo pouco importante podem indicar uma abrangência de versão ampla demais; conflitos frequentes em uma decisão crítica podem indicar que falta coordenação entre equipes. O indicador é um ponto de investigação, não prova de erro humano.

Teste concorrência controlada e acompanhe o salvamento

Crie um teste em que duas atualizações partem da mesma versão e são liberadas juntas. O resultado esperado deve ser uma confirmação e uma rejeição de precondição, preservando a mudança vencedora conforme a ordem efetiva de gravação. Não dependa de cliques manuais rápidos para demonstrar a proteção. Teste também atualização por tarefa automática, salvamento repetido após sucesso e leitura seguida de exclusão. Confira o estado final e a nova versão, além do código de resposta.

Valide o fluxo humano com duas pessoas ou sessões independentes. Uma delas deve conseguir concluir a revisão sem perder o rascunho e sem precisar compreender detalhes do protocolo. Meça quantas vezes é necessário reabrir a tarefa e se as mensagens ajudam a identificar o que mudou. Um controle tecnicamente correto pode gerar frustração se a interface não preserva conteúdo ou apresenta diferenças incompreensíveis. A solução precisa proteger a gravação e permitir continuar o trabalho.

Após publicar, acompanhe tentativas sem versão, conflitos por tipo de recurso e abandono após conflito. Esses sinais ajudam a encontrar clientes antigos e regras excessivamente abrangentes. Documente a política de combinação e os escritores autorizados do recurso para futuras integrações. O resultado esperado é simples de explicar: ninguém recebe sucesso por substituir uma versão que já não era a que revisou, e toda colisão tem um caminho claro para uma nova decisão.

Perguntas frequentes

Salvar somente os campos alterados resolve?

Reduz algumas colisões, mas campos diferentes podem participar da mesma regra. Ainda é necessário definir quando as mudanças são compatíveis e verificar concorrência na gravação.

É preciso bloquear a tela para os demais usuários?

Não necessariamente. Um controle otimista permite edição paralela e verifica a versão ao salvar. Bloqueios explícitos podem ser adequados em outros contextos, mas precisam de prazo e recuperação.

Posso repetir o salvamento após receber um conflito?

Não de forma cega. Primeiro apresente ou reavalie as mudanças atuais. A nova tentativa precisa representar uma decisão sobre a versão mais recente, preservando as regras do negócio.

Proteja o trabalho simultâneo da sua equipe

A Tironi Tech pode desenvolver formulários, APIs e regras de concorrência para que alterações administrativas tenham confirmação e resolução de conflitos.

Artigos relacionados

• Como atualizar uma dependência de software sem perder o controle do impacto
• Como modernizar um sistema legado substituindo um módulo de cada vez
• Como planejar um teste de carga que represente as jornadas do sistema

Fontes consultadas

• MDN — If-Match header