APRENDER. PRATICAR. EVOLUIR.Arredondar a operação certa
Para GetItem, uma leitura forte de um item até 4 KiB consome uma unidade de leitura; a eventual consome metade. Um item de 6 KiB ocupa dois blocos, logo duas unidades fortes ou uma eventual. Em BatchGetItem, arredonda cada item separadamente: itens de 1 KiB e 5 KiB dão três unidades fortes. Não transfiras esta regra sem análise para Query, que agrega tamanhos antes do arredondamento. Identifica operação, tamanho e consistência antes de calcular; uma taxa de pedidos isolada é insuficiente.
Separar consumo, resposta e preço
Uma ProjectionExpression que devolve 100 bytes de um item de 9 KiB não reduz o consumo GetItem para 100 bytes: a leitura forte continua a usar três unidades. Num UpdateItem não transacional, considera o maior tamanho antes ou depois e arredonda para blocos de 1 KiB; de 2,2 para 2,6 KiB são três unidades de escrita, excluindo índices neste exemplo. Os cálculos ensinam consumo. Para estimar custo monetário, ainda precisas de modo de capacidade, região, índices e outros serviços utilizados.
Escolher consistência no caminho de acesso
Tabelas e local secondary indexes suportam leituras fortes; global secondary indexes não. Pedir ConsistentRead num GSI não converte o índice num destino forte. Se a confirmação exige atualização imediata, revê o acesso à tabela ou um LSI adequado, em vez de acrescentar uma opção inválida. Estes exercícios usam uma região. Não generalizes que todas as global tables têm sempre consistência eventual: existem modos de consistência distintos e requisitos próprios. No desenho, escreve o requisito ao lado de cada acesso, não apenas no título da base de dados.
Tornar a condição parte da alteração
Dois workers podem ler saldo 100, ambos decidir reservar 80 e só depois escrever. Uma leitura forte não bloqueia a alteração do outro worker entre essas operações. No exercício de um único item, um UpdateItem com condição saldo>=80 verifica e altera atomicamente; após a primeira reserva ficam 20 e a segunda condição falha. Trata esse resultado na aplicação. Isto não coordena automaticamente uma chamada externa de pagamento. Identidade estável, idempotência no destino e reconciliação continuam relevantes quando o efeito atravessa sistemas.
Não usar limpeza como autorização
DynamoDB TTL elimina itens de forma assíncrona. Se um token expira às 12:00, a sua presença às 12:01 não o torna válido. A aplicação deve aplicar a regra de expiração ao autorizar, enquanto TTL trata a limpeza. De forma semelhante, DAX não elimina a necessidade de escolher consistência: leituras fortes passam para DynamoDB e não são servidas nem guardadas pela cache DAX. Uma solução de cache precisa de corresponder à semântica das leituras, não apenas ao desejo de reduzir latência.
Distribuir chaves e preparar operação
Uma partition key igual a hoje para todas as escritas pode concentrar tráfego mesmo quando a capacidade total parece suficiente. Começa pelos padrões de acesso e distribuição de chaves. Sharding pode repartir carga, mas também altera consultas, agregação e manutenção; não é uma escolha gratuita. No caso de 120 GetItem por segundo sobre 6 KiB, metade fortes e metade eventuais, o consumo é 60×2+60×1=180 unidades por segundo. Esse total ainda não demonstra distribuição adequada, tolerância a picos ou latência aceitável.
Dois workers tentam reservar 80 de um saldo 100; uma alteração condicional bem-sucedida deixa 20 e impede a segunda reserva.
Armadilhas comuns
Usar GSI como leitura forte, TTL como revogação imediata ou leitura seguida de escrita como operação atómica.
Tópicos relacionados: Idempotência · Modelação de dados
Consistência, atomicidade, capacidade e validade são requisitos diferentes e precisam de decisões explícitas.
Referência: DynamoDB read and write operations · SAA-C03