Um agente consulta o pedido para alterar o endereço. Enquanto ele prepara a ação, uma pessoa muda a quantidade e outro fluxo cancela um item. Se a primeira gravação enviar uma cópia inteira do registro antigo, pode desfazer decisões que aconteceram durante a conversa, mesmo tendo entendido corretamente a solicitação.
Esse é um problema de concorrência sobre o mesmo estado. Ele existe com pessoas, integrações tradicionais e agentes. A diferença é que a conversa e as aprovações podem ampliar o intervalo entre leitura e escrita. É preciso definir o que fazer quando o mundo muda nesse intervalo.
Duplicidade e conflito são problemas distintos
Idempotência ajuda a reconhecer repetições da mesma operação. Ela não decide entre duas solicitações legítimas que disputam o mesmo registro. Alterar o endereço e cancelar a entrega podem ter chaves diferentes e ainda assim exigir coordenação para produzir um resultado coerente.
Mapeie quais campos e consequências podem avançar independentemente. Duas mudanças em campos diferentes nem sempre são compatíveis: trocar a filial pode invalidar preço, estoque e endereço. A regra de conflito precisa representar o processo, e não apenas comparar nomes de colunas.
Use versões quando o sistema oferecer esse contrato
A RFC 9110 descreve If-Match para condicionar uma alteração ao estado identificado por um validador. Essa precondição ajuda a impedir que um cliente sobrescreva alterações concorrentes quando o servidor implementa o mecanismo corretamente.
A aplicação deve conservar a versão consultada e enviá-la na tentativa de atualização, ou usar mecanismo equivalente oferecido pelo sistema. Quando houver conflito, recupere o novo estado. Não repita automaticamente a mesma escrita retirando a condição que justamente detectou o problema.
Exemplo composto: endereço alterado após cancelamento
Numa empresa fictícia, o atendimento prepara uma mudança de endereço enquanto a logística cancela a entrega. A ferramenta rejeita a alteração porque a versão do pedido mudou. O agente consulta novamente e descobre que a solicitação original já não possui o mesmo efeito possível.
Em vez de restaurar a entrega ou gravar o endereço à força, ele explica a mudança de estado e encaminha a próxima decisão. A pessoa pode querer atualizar apenas o cadastro para pedidos futuros. Essa é uma nova intenção, que exige autorização própria, e não uma continuação automática da escrita rejeitada.
Escolha uma estratégia compatível com o legado
Se a API oferece atualização condicional, use-a de ponta a ponta. Se não oferece, avalie uma camada de integração capaz de coordenar as escritas com o sistema responsável. Uma fila por entidade pode reduzir conflitos entre os fluxos que passam por ela, mas não controla usuários ou integrações externas que a contornam.
Defina quando comparar campos, quando revalidar regras e quando pedir uma decisão humana. Evite bloqueios longos durante conversas, porque a pessoa pode demorar ou abandonar a tarefa. A solução deve combinar tempo de validade, conferência antes da gravação e recuperação após conflito.
Checklist para testar alterações simultâneas
- Identifique todos os caminhos que escrevem no mesmo registro.
- Teste duas ações válidas em ordens diferentes.
- Inclua alterações humanas durante espera e aprovação.
- Confira se a integração preserva versões e precondições.
- Meça conflitos, sobrescritas detectadas e esforço de reconciliação.
Nos testes, introduza pausas deliberadas entre consulta e atualização. Esse intervalo reproduz o risco melhor do que executar tudo em sequência rápida. Verifique o estado final do sistema e as mensagens ao usuário; uma rejeição bem tratada pode ser o resultado correto, sem representar falha de qualidade do agente.
Como a Uiless ajuda
Os contratos de ferramentas da Uiless podem representar parâmetros e validações do sistema integrado. A proteção contra escrita concorrente depende do suporte real do conector e do destino. Idempotência continua útil, mas não deve ser apresentada como solução universal para conflitos entre operações distintas.
Relacione este tema a integrações resilientes e a aprovações que chegam depois de uma mudança. Ambos exigem conferir o estado no momento em que a consequência será aplicada.
