APRENDER. PRATICAR. EVOLUIR.Começar pelo invariante e pelo caminho de leitura
Antes de selecionar uma base de dados, escreve o que nunca pode acontecer: uma reserva repetida, uma leitura que autoriza com estado antigo ou duas regiões que aceitam a mesma exclusividade. Em DynamoDB, tabelas e LSIs suportam leitura forte, mas GSIs não. Uma consulta GSI pode ainda não refletir uma escrita acabada de confirmar. O desenho precisa de um caminho que satisfaça a necessidade; não basta acrescentar ConsistentRead a um índice que não o suporta. Uma leitura forte também não bloqueia o item contra alterações posteriores. No exercício, dois workers leem saldo 80 e ambos querem reservar 60. Ler o mesmo valor atualizado não arbitra a disputa. A condição relevante deve fazer parte da operação de escrita ou da transação apropriada; a aplicação tem de tratar rejeição e reavaliar o resultado.
Fronteira da transação e repetição do pedido
TransactWriteItems agrupa alterações atómicas na mesma conta e região; BatchWriteItem pode ter sucesso parcial. Não uses duas ações sobre o mesmo item na mesma transação: uma condição sobre o item atualizado pode acompanhar o próprio Update. O token de pedido apoia idempotência durante dez minutos após a conclusão inicial. Um replay de negócio no dia seguinte precisa de uma estratégia que sobreviva a essa janela. No exercício, o registo de processamento e a reserva estão em itens distintos na mesma região. A proposta é criá-los atomicamente com condições adequadas, guardando identidade e resultado durante o horizonte de replay definido. Uma chamada a um processador externo não passa a fazer parte dessa transação. Identifica essa fronteira e prevê confirmação ou reconciliação do resultado externo. Mantém exemplos de timeout antes e depois do commit para evitar repetir cegamente.
Replicação eventual não cria exclusividade global
As global tables atuais distinguem MREC de MRSC. Em MREC, a replicação é assíncrona, conflitos do mesmo item convergem por last writer wins e condições são avaliadas contra a versão local. Dois pedidos em regiões diferentes podem passar uma condição de ausência antes de a escrita remota chegar. Uma leitura forte local não força a chegada de uma alteração feita noutra região. Também não deves apresentar uma transação regional de vários itens como unidade atómica nas réplicas: os itens podem aparecer em momentos diferentes. Para uma exclusividade global, revê o desenho com uma autoridade de escrita ou um mecanismo que satisfaça realmente o invariante, incluindo o failover dessa autoridade. Num ensaio, regista os dois resultados aceites e o estado que converge; um estado final único não apaga efeitos externos produzidos pelas duas aceitações.
Escolher MRSC sem prometer funcionalidades inexistentes
MRSC fornece leituras fortes globais em réplicas quando se pede leitura forte e avalia condições sobre a versão mais recente. A documentação consultada exige três regiões, com três réplicas ou duas e um witness; o witness não serve pedidos de leitura ou escrita da aplicação. As regiões devem pertencer a um conjunto suportado. Verifica também funcionalidades: MRSC não suporta operações transacionais, TTL ou LSIs na documentação atual. Não é um substituto transparente para qualquer desenho MREC. O modo de consistência não pode ser alterado numa global table existente. Um projeto que precisa de mudar deve planear novo desenho, dados, transição e validação, em vez de prometer um simples toggle. A prova de aceitação inclui latência observada, comportamento de falha, garantia do invariante e compatibilidade das operações usadas pela aplicação.
Original MREC thought experiment; not AWS deployment code
Initial: reservation K absent in replica A and replica B
A: conditional create K accepted before replication
B: conditional create K accepted before replication
Later: replicas converge on one item version
Question: did convergence undo either external effect?
Answer: no; application arbitration/reconciliation is requiredDuas regiões MREC aceitam a mesma reserva antes da replicação. A convergência posterior não prova que só ocorreu um efeito no processador externo.
Armadilhas comuns
Tratar leitura forte como lock; usar GSI para frescura garantida; estender transações a serviços externos; assumir atomicidade entre réplicas MREC; prometer TTL ou transações em MRSC.
Tópicos relacionados: Filas, repetição e recuperação
Cada garantia tem um âmbito; demonstra o invariante no âmbito em que o negócio o exige.
Referência: DynamoDB read consistency · SAP-C02