Leituras Fortemente Consistentes vs Eventualmente Consistentes no DynamoDB

Você atualiza um item, imediatamente o consulta de volta e recebe o valor antigo. A escrita teve sucesso — um instante depois a mesma leitura retorna o novo valor. Nada está quebrado: você bateu na leitura eventualmente consistente padrão do DynamoDB, e pode optar por sair dela por requisição.

Este é um dos poucos botões de correção que o DynamoDB te entrega diretamente, e ele tem um preço real anexado. Acertá-lo significa saber o que cada modo garante, quanto custa, e onde leituras fortes simplesmente não estão disponíveis.

Qual é a diferença entre leituras fortemente consistentes e eventualmente consistentes no DynamoDB?

Uma leitura eventualmente consistente (o padrão) é servida por qualquer réplica, então pode retornar dados obsoletos por um breve momento logo após uma escrita, mas custa metade do preço. Uma leitura fortemente consistente, ativada por requisição com ConsistentRead=true, é roteada para o líder da partição e sempre reflete cada escrita confirmada — ao custo de 2× a capacidade de leitura.

• Eventualmente consistente (o padrão) — pode retornar dados obsoletos por um breve momento logo após uma escrita. O modo de leitura mais barato.
• Fortemente consistente — sempre reflete cada escrita confirmada antes da leitura. Opte por entrar por requisição com ConsistentRead=true.
• Leituras fortes custam 2× as eventuais. Uma leitura fortemente consistente consome o dobro da capacidade de leitura de uma eventualmente consistente para os mesmos dados.
• Não em todo lugar. Você tem leituras fortes na tabela base e em um Índice Secundário Local. Um Índice Secundário Global é apenas eventual — sem opção de entrada.
• Padrão para eventual. Recorra a forte apenas quando estiver lendo seus próprios dados recém-escritos e obsoleto-por-um-instante seria errado.

O problema: uma leitura que não vê a última escrita

Digamos que você administra contas de usuário. Um usuário troca o e-mail de notificação, sua aplicação escreve a atualização, e a tela de confirmação imediatamente relê o perfil para mostrar o novo endereço. Com o modo de leitura padrão, essa releitura pode cair em uma réplica que ainda não recebeu a mudança — então o usuário vê seu e-mail antigo e presume que o salvamento falhou.

A janela é pequena (tipicamente bem menos de um segundo) e fecha por conta própria. Mas "geralmente correto" não é bom o suficiente para uma confirmação de leitura-após-escrita. Esse é exatamente o caso para o qual a consistência forte existe.

Por que a consistência eventual acontece

O DynamoDB armazena cada partição em três nós de armazenamento — um primário e duas réplicas — distribuídos por Zonas de Disponibilidade separadas. Uma escrita é confirmada assim que pousa no primário e em uma réplica; ela então propaga para o terceiro nó de forma assíncrona.

Leituras, para distribuir carga, podem ser servidas por qualquer um dos três nós. Uma leitura eventualmente consistente pode bater em um nó que ainda não recebeu sua escrita mais recente — então ela retorna um valor levemente obsoleto. Uma leitura fortemente consistente é roteada para o líder da partição, que sempre detém os dados confirmados mais recentes, então nunca retorna resultados obsoletos.

Esse atraso de replicação é a diferença inteira. Ele também explica o custo de 2×: leituras fortes não podem ser balanceadas entre as réplicas do jeito que as eventuais podem, então o DynamoDB as precifica ao dobro da capacidade.

O custo, concretizado

Leituras são medidas em Unidades de Capacidade de Leitura (RCU), cada uma cobrindo até 4 KB. Uma RCU compra uma leitura fortemente consistente ou duas leituras eventualmente consistentes de um item de 4 KB. Então ativar ConsistentRead=true em um caminho de leitura quente dobra seu custo de leitura — em um endpoint de alto tráfego isso é um item de linha que você vai notar.

Modele a diferença para seus próprios tamanhos de item e taxas de requisição com a calculadora de preços do DynamoDB antes de tornar as leituras fortes seu padrão — raramente vale pagar o dobro de forma generalizada.

Onde leituras fortes estão (e não estão) disponíveis

Um GSI mantém sua própria cópia dos dados, replicada da tabela base de forma assíncrona, então ele nunca pode oferecer uma leitura forte. Se um padrão de acesso genuinamente precisa de leitura-após-escrita e você planejava servi-lo a partir de um GSI, isso é um sinal para servi-lo a partir da tabela base ou de um LSI em vez disso.

Ciladas e próximos passos

• Não torne as leituras fortes o padrão. A maioria das leituras tolera uma janela obsoleta sub-segundo; pagar 2× em todo lugar é gasto desperdiçado.
• Não espere leitura-após-escrita de um GSI. É eventual por design — veja por que um GSI é eventualmente consistente.
• Transações leem de forma forte. TransactGetItems é sempre fortemente consistente — veja transações no DynamoDB.
• Consistência interage com capacidade. O multiplicador de 2× se liga diretamente ao planejamento de custo on-demand vs provisionado.

Quer explorar suas tabelas e índices do DynamoDB sem escrever chamadas de API? Baixe o DynoTable e inspecione seus dados diretamente.