trilha

Tecnologias/02 - Bancos de Dados/02 - Não Relacionais/02 - DynamoDB2 min

Consistência e Transações no DynamoDB

Consistência de leitura

Uma leitura eventualmente consistente pode retornar uma versão anterior enquanto alterações se propagam. Uma leitura fortemente consistente reflete as escritas bem-sucedidas anteriores à leitura, dentro das garantias documentadas.

Tabelas e LSIs permitem leituras fortes. Leituras de GSIs são eventualmente consistentes; definir ConsistentRead não transforma um GSI em índice de leitura forte. Referência: consistência.

Escrita condicional

Uma condição faz a alteração depender do estado observado pelo próprio banco durante a operação. Isso evita separar a decisão em uma leitura e uma escrita desprotegidas.

UpdateItem no estoque de um produto:
  UpdateExpression:    SET saldo = saldo - :qtd
  ConditionExpression: saldo >= :qtd

Se o saldo já não atende à condição, a atualização falha. Ler saldo 10, calcular 9 na aplicação e depois sobrescrever o valor pode perder alterações concorrentes; uma condição ou operação apropriada precisa representar a regra pretendida. Referência: condições.

Transações

TransactWriteItems reúne alterações e verificações condicionais em uma operação atômica. TransactGetItems obtém uma leitura transacional dos itens indicados. Essas APIs têm limites e escopo definidos, incluindo a mesma conta e região nas operações descritas pela documentação. Referência: transações.

Exemplo

Criar um pedido e reservar estoque pode exigir duas alterações como uma unidade. Se o estoque não atender à condição, a transação deve falhar sem criar o pedido. Uma leitura posterior por GSI ainda pode apresentar atraso de propagação; atomicidade da escrita não modifica as garantias de leitura desse índice.

Aprofundamento aplicado

Condição protege saldo; idempotência protege repetição

Decrementar estoque com saldo >= :qtd impede ficar negativo, mas repetir a mesma compra ainda pode descontar duas vezes se houver saldo. As duas propriedades exigem mecanismos diferentes.

Um desenho possível usa uma transação que cria um registro de operação com chave única e condição de ausência, além de atualizar o estoque com a condição de saldo. Se a mesma operação reaparecer, a aplicação consulta seu resultado em vez de fazer uma nova reserva. Defina também como detectar a mesma chave com conteúdo diferente.

O ClientRequestToken de TransactWriteItems oferece idempotência durante a janela documentada de 10 minutos; uma regra que precisa deduplicar por dias exige estratégia persistente com retenção correspondente. Referência: idempotência transacional.

Exercício: represente queda da conexão depois do commit e antes da resposta. Resultado esperado: o retry com o mesmo identificador não reserva novamente; o cliente consegue reconciliar o resultado sem interpretar timeout como rollback.

Relacionado: 6. Transações e ACID · Idempotent Operations · 1. DynamoDB.


Parte de DynamoDB

Buscar

Busca por título, seção e texto das notas