Identidade, estados e recuperação de operações

1. Começar pelo resultado e pelos estados

Numa plataforma fictícia de instruções de fundos, o negócio pretende que cada instrução autorizada produza um movimento e um resultado consultável. Receber uma mensagem, validar campos, aceitar trabalho e confirmar o movimento são acontecimentos diferentes.

Desenha-os antes de discutir códigos ou ferramentas. Um estado recebido não deve fazer o utilizador acreditar que o movimento já existe. A resposta HTTP 202 admite processamento pendente; o contrato da aplicação precisa de explicar como o resultado será acompanhado.

Escreve para cada estado quem o produz, que evidência o sustenta e quais transições são permitidas. Um timeout observado pelo cliente descreve falta de resposta nessa tentativa. A operação pode continuar no servidor.

Separar estado da operação e conhecimento do cliente evita transformar silêncio em rejeição definitiva.

2. Distinguir identidade, conteúdo e intenção

A analista recebe três registos: cliente A, chave K7, 100 unidades; cliente A, chave K7, 100 unidades; cliente B, chave K7, 100 unidades. O contrato fictício define a identidade por cliente autorizado e chave. Os dois primeiros registos são tentativas da mesma operação; o terceiro pertence a outra identidade.

Isto não concede a A acesso ao resultado de B. A correlação usada no diagnóstico também não substitui a autenticação e a autorização. Acrescenta ao dicionário a origem da chave, o seu âmbito, a persistência entre tentativas e a forma de localizar a operação.

Dois pedidos com conteúdo igual podem representar duas instruções legítimas. Se a intenção for diferente, usar apenas o hash do conteúdo para os fundir pode eliminar trabalho solicitado pelo negócio.

3. Repetição e alteração são decisões diferentes

A instrução A/K7 foi aceite com 100 unidades. Um pedido posterior usa A/K7 e 140 unidades. A política do exercício rejeita conteúdo diferente para a mesma identidade e conserva a operação anterior.

Assim, repetir com 140 não altera silenciosamente a instrução aceite. Uma alteração terá um processo próprio, sujeito ao estado atual e à autoridade aplicável. Identifica também quais campos participam na comparação.

Espaços de apresentação, campos de diagnóstico e valores de negócio não têm necessariamente a mesma função. Não inventes uma regra de normalização durante um incidente. Prepara exemplos com a equipa: conteúdo igual, conteúdo de negócio alterado, cliente diferente e nova intenção com conteúdo igual.

Regista o resultado esperado de cada exemplo e valida-o com produtores e consumidores.

4. Colocar a falha na sequência concreta

Considera um modelo local com duas escritas: registar o movimento e guardar a identidade tratada. Se o movimento ficar confirmado e houver falha antes da segunda escrita, uma repetição pode parecer nova. Inverter a ordem sem mais condições também não resolve: guardar a identidade e falhar antes do movimento pode impedir uma execução ainda necessária.

No exercício, as duas escritas pertencem à mesma transação local: ou ambas ficam confirmadas ou nenhuma fica. Pede evidência de falha antes do commit e de perda da resposta depois do commit. No primeiro caso, a repetição ainda pode criar o movimento; no segundo, deve recuperar o resultado já guardado.

A propriedade de idempotência respeita o efeito pretendido; não exige respostas byte a byte iguais nem proíbe um novo registo de diagnóstico.

5. Não alargar a prova para além da fronteira

Agora o movimento é produzido num parceiro externo. A base local confirma a mensagem enviada, mas a resposta do parceiro perde-se. Uma transação na base local não desfaz automaticamente um efeito confirmado no parceiro.

A análise precisa de um contrato entre serviços: identidade compreendida no destino, consulta fiável, tratamento de repetições e reconciliação quando a execução permanece desconhecida. Um ecrã de consulta alimentado por uma cópia atrasada pode não ser prova de não execução.

No caso fictício, o feed secundário chega até cinco minutos depois; não encontrar a operação aí após dez segundos deixa o resultado em aberto. Define quem investiga, que fonte permite concluir e quais ações dependem dessa conclusão. Nunca transformes uma demonstração local de duas escritas numa promessa de execução única entre sistemas independentes.

6. A proteção também tem uma janela temporal

O cliente pode repetir durante 72 horas, mas a proposta conserva identidades durante 24. Há uma lacuna entre o comportamento permitido e a memória usada para o reconhecer. Não basta declarar que existe uma chave. Compara janelas, relógio de referência, expiração, consulta de resultados e tratamento de pedidos antigos. No exercício, a idade é calculada desde a primeira aceitação e a proteção abrange idades inferiores a 24 horas; exatamente 24 já está fora. Esta fronteira é uma escolha didática explícita, não uma regra HTTP nem uma recomendação universal de retenção. O projeto pode alinhar janelas ou encaminhar pedidos antigos para uma via de reconciliação que impeça a execução automática indevida. Custos de armazenamento e necessidades operacionais entram na decisão com responsáveis definidos.

Exemplo com offsets explícitos: de 24 de outubro às 12:00+01:00 até 25 de outubro às 12:00+00:00 passam 25 horas, pois os instantes são 11:00 UTC e 12:00 UTC do dia seguinte. Uma regra de idade inferior a 24 horas não cobre a segunda tentativa. O exemplo recebe os offsets como dados; não deduz regras de um país. Define também o evento que inicia a contagem, a inclusão ou exclusão do limite e a fonte do relógio.

7. Confirmar o que cancelar significa

Uma operação está em execução quando o utilizador pede cancelamento. A interface mostra pedido de cancelamento recebido, mas isso não demonstra que o movimento foi evitado. Especifica o ponto a partir do qual o cancelamento já não pode impedir o efeito e qual fonte decide a ordem dos acontecimentos.

Na política fictícia, uma decisão atómica do serviço resolve a corrida: se cancelar vencer antes do commit, o resultado será cancelado sem movimento; se o commit vencer, o resultado será concluído e o cancelamento será recusado como tardio.

Não se escolhe a ordem pelo momento em que notificações chegam ao ecrã. Se for necessário reverter um movimento concluído, será uma nova ação de negócio autorizada, com histórico próprio. Apagar o registo anterior destrói a explicação do que aconteceu.

8. Exercício: preparar a decisão de recuperação

Antes de consultar a análise comentada, classifica quatro ocorrências no contrato local: A/K7 já tem movimento M7 confirmado e perde a resposta; A/K8 falha antes de confirmar as duas escritas; A/K7 reaparece com 140 em vez de 100 unidades; B/K7 chega como nova instrução autorizada.

Decide qual identidade existe, se pode ser criado um movimento e qual informação deve ser devolvida. Análise comentada: a repetição de A/K7 recupera M7; A/K8 pode ser executada porque nada ficou confirmado; A/K7 alterada exige conflito sem mudar M7; B/K7 é outra identidade e pode criar o seu movimento.

Depois muda uma condição: M7 pertence ao parceiro externo e só existe um feed atrasado. Explica por que a decisão de reenviar deixa de resultar apenas da base local. Entrega um quadro de estados, pressupostos, fontes de verdade e perguntas em aberto para negócio, desenvolvimento e APS.

Armadilhas comuns

Usar conteúdo igual como prova de intenção igual; aceitar conteúdo alterado com a mesma chave; confundir timeout com rejeição; generalizar uma transação local; cancelar apenas no ecrã; ignorar a expiração da identidade.