APRENDER. PRATICAR. EVOLUIR.Conceito e mecanismo
Uma leitura seguida de escrita não é uma verificação atómica. Dois workers podem observar a mesma ausência e tentar criar o mesmo item. Uma condição avaliada durante PutItem protege essa chave de substituição; trata a falha da condição como um resultado de concorrência que exige interpretação. Para mudanças relacionadas em vários itens, uma transação DynamoDB pode fornecer atomicidade dentro do âmbito suportado. Isso não inclui uma chamada a um fornecedor externo. O desenho deve explicar como se recupera de falhas entre fronteiras. Leituras fortemente consistentes na tabela podem confirmar um estado recente; GSIs usam consistência eventual e podem mostrar a atualização mais tarde.
Aplicação guiada
Um relatório pode estar errado sem qualquer erro HTTP. Query devolve páginas e o filtro é aplicado depois de ler os itens. Uma página sem correspondências pode ainda ter LastEvaluatedKey. Continua com o token recebido e a mesma condição até não existir continuação; não uses Items.length como único critério de fim. Se descartas quase tudo com o filtro, revê as chaves e o padrão de acesso, porque o filtro não recupera a capacidade de leitura já consumida. Num ensaio, inclui páginas vazias intermédias, escritores concorrentes e leitura logo após escrita. Verifica também que a consulta mantém a carteira e o cliente autorizados.
Para criar o registo de operação op-87 uma única vez, usa uma escrita condicional nessa chave. Se o registo já existe, consulta o estado em vez de gerar outra identidade para contornar a condição.
Armadilhas comuns
Leitura forte como lock; GSI como confirmação imediata; filtro como redução garantida de capacidade; transação como proteção de sistemas externos.
Tópicos relacionados: Identidades e autorização por recurso · Segredos, chaves e logs úteis
As garantias pertencem a operações e fronteiras concretas, não a toda a aplicação por associação.
Referência: DynamoDB conditional writes · DVA-C02; exam guide 2.1