Read Replica, Primary e Consistência de Leitura

O problema

Tem conversa de arquitetura que acontece assim:

• “o banco esta sofrendo”
• “joga leitura na replica”
• “resolvido”

As vezes alivia carga.

Também pode criar um efeito bem irritante:

• usuário salva
• abre a tela logo depois
• ainda ve o valor antigo

Quando isso acontece, o time descobre tarde que o problema nunca foi só performance.

Era consistência de leitura.

Modelo mental

Pense assim:

primary recebe a escrita primeiro; replica aprende depois

Esse “depois” pode ser pequeno.

Mas não e zero por definição.

Entao a pergunta deixa de ser:

“Posso usar replica?”

E vira:

“Esse fluxo aceita ler um estado um pouco atrasado?”

Se aceita, replica pode ser uma otima troca.

Se não aceita, jogar a query na replica e um jeito elegante de fabricar bug de percepção.

Quebrando o problema

O que a replica compra

Replica costuma ajudar em:

• distribuir leitura
• aliviar o primary
• melhorar disponibilidade de leitura
• escalar consultas menos críticas

Isso e valioso.

Mas não vem gratis.

O que a replica custa

O custo mais importante e o lag de replicação.

Ou seja:

• a escrita entrou no primary
• a replica ainda não recebeu ou aplicou aquele estado

Resultado:

• a leitura na replica pode ver o passado

Em algumas telas isso passa despercebido.

Em outras, parece que o sistema mentiu.

Nem toda leitura merece o mesmo caminho

Leitura perto de escrita recente costuma ser a mais sensivel.

Exemplos:

• usuário acabou de editar o próprio perfil
• operação mudou saldo ou limite
• painel mostra resultado de ação que o usuário acabou de disparar

Já leitura menos crítica pode tolerar atraso:

• feed
• ranking
• dashboard agregado
• relatório não operacional

O erro comum e mandar tudo para replica como se toda leitura tivesse o mesmo risco.

Read-your-own-writes muda a experiência

Mesmo num sistema com replica, você pode querer garantir que quem acabou de escrever veja o próprio resultado.

Isso pode ser feito de vários jeitos:

• ler do primary em fluxos sensiveis
• manter afinidade temporária com o primary
• usar cache ou sessao para proteger a leitura logo depois da escrita

O nome técnico importa menos do que o efeito:

O usuário não pode sentir que a própria ação desapareceu.

Replica não corrige problema de escrita

Se o gargalo esta no primary por causa de escrita pesada, replica ajuda pouco.

Ela tira leitura da frente.

Não multiplica capacidade de escrita do primary.

Esse detalhe evita muita resposta automática errada em entrevista e em projeto real.

Exemplo simples

Imagine uma tela de pedidos.

O usuário acabou de cancelar um pedido e a API confirma sucesso.

Se a tela logo em seguida consulta replica atrasada, ela pode mostrar o pedido ainda como active.

Do ponto de vista do usuário, isso parece:

• bug
• timeout esquisito
• ação que não funcionou

O mesmo atraso, em um dashboard de pedidos por dia, talvez fosse irrelevante.

Não e a replica que esta certa ou errada.

E o contexto da leitura.

Erros comuns

• Tratar replica como solução universal de performance.
• Esquecer que leitura logo apos escrita costuma ser sensivel.
• Ignorar lag de replicação na modelagem do produto.
• Mandar consulta crítica para replica porque “quase sempre esta atualizada”.
• Falar de replica como assunto só de banco e esquecer a experiência percebida.

Como um senior pensa

Quem tem mais experiência costuma perguntar:

“Se essa leitura vier alguns segundos atrasada, o que exatamente o usuário ou o negócio vai perceber?”

Essa pergunta vale mais do que discutir replica em abstrato.

Senioridade aqui aparece em ligar topologia de banco ao comportamento visível do sistema.

O que o entrevistador quer ver

Em entrevista, o avaliador quer ver se você entende o trade-off real.

Você sobe de nivel quando:

• fala de lag de replicação
• diferencia leitura crítica de leitura tolerante a atraso
• menciona read-your-own-writes ou estratégia equivalente
• reconhece que replica não resolve gargalo de escrita

Uma resposta forte costuma soar assim:

“Eu usaria replica para leituras que toleram atraso, mas manteria no primary os fluxos que precisam refletir escrita recente, como confirmação imediata para o próprio usuário. Replica ajuda performance, mas muda o modelo de consistência da leitura.”

Replica boa não e a que recebe mais query. E a que não quebra a expectativa errada do fluxo certo.

Quando a leitura importa mais do que o throughput, consistência deixa de ser detalhe de infra.