Lag de Replicação Sem Surpresa em Produto

O problema

Time de backend costuma falar de réplica assim:

• melhora leitura
• reduz carga no primary
• aumenta disponibilidade

Tudo isso é verdade.

O problema é que o usuário não enxerga réplica.

Ele enxerga isto:

• clicou em salvar
• recebeu sucesso
• abriu a tela seguinte
• ainda viu o dado antigo

Para ele, o sistema não está “com lag de replicação”.

Ele só parece errado.

Modelo mental

Pense assim:

lag de replicação é atraso técnico que vira surpresa de produto quando a leitura contradiz a última ação do usuário

Essa definição ajuda porque conecta infraestrutura e experiência.

O atraso em si pode ser pequeno.

Mas se ele aparece justo no momento em que o usuário precisa confiar que a ação aconteceu, o dano percebido sobe muito.

Quebrando o problema

O mesmo lag muda de peso dependendo do fluxo

Dois segundos de atraso podem ser:

• irrelevantes em dashboard agregado
• chatos em contagem de likes
• inaceitáveis em cancelamento de pedido

Então a pergunta certa não é:

“Qual o lag da réplica?”

E sim:

“Onde esse lag aparece e o que ele comunica para o usuário?”

A pior leitura é a leitura logo após escrita

A maioria das reclamações nasce aqui:

• atualizou perfil e continua vendo o valor velho
• confirmou cancelamento e a tela mostra estado antigo
• acabou de criar algo e a listagem diz que não existe

Esse é o ponto em que read-your-own-writes deixa de ser luxo e vira proteção de confiança.

Nem todo fluxo precisa ser empurrado para o primary

Mandar tudo para o primary resolve parte da dor.

Também mata boa parte do ganho da réplica.

Melhor costuma ser pensar em exceção consciente:

• leitura crítica após escrita vai ao primary
• consulta menos sensível pode ir para réplica
• fallback existe quando a frescura do dado importa mais do que a escala daquela tela

Isso pede critério por fluxo, não regra única.

Afinidade temporária funciona bem em momentos sensíveis

Às vezes você não precisa abandonar réplica.

Só precisa dizer:

• “por alguns segundos depois da escrita, esse usuário lê do primary”

Esse tipo de afinidade temporária reduz a sensação de ação sumindo.

Não é a única estratégia.

Mas é uma estratégia prática e honesta.

Produto precisa participar da conversa

Esse tema costuma ficar preso entre infra e backend.

Mas quando lag aparece na experiência, a pergunta também é de produto:

• esse atraso é aceitável aqui?
• a interface precisa indicar processamento?
• faz sentido mostrar estado transitório?

Sem essa conversa, o time técnico otimiza leitura e o produto paga a conta na confiança do usuário.

Exemplo simples

Imagine um app de entregas.

O usuário acabou de trocar o endereço padrão.

A API responde sucesso.

Na sequência, a tela de checkout lê de réplica e mostra o endereço antigo.

O problema não é só técnico.

O usuário agora dúvida:

• se a mudança realmente salvou
• se precisa tentar de novo
• se o pedido vai para o lugar errado

Talvez bastasse fazer a leitura desse fluxo ir ao primary por alguns segundos depois da atualização.

O custo e pequeno.

A confiança salva é grande.

Erros comuns

• Tratar lag como assunto invisível para usuário.
• Mandar leitura crítica para réplica porque “quase sempre está atualizada”.
• Resolver tudo levando tudo para o primary.
• Não diferenciar dashboard tolerante de fluxo operacional sensível.
• Esquecer que UI pode precisar mostrar estado transitório em vez de fingir sincronia perfeita.

Como um senior pensa

Quem tem mais experiência costuma perguntar:

“Onde esse atraso vira contradição visível e o que eu faço para o usuário não sentir que a ação evaporou?”

Essa pergunta é muito melhor do que discutir réplica só em TPS e CPU.

O que o entrevistador quer ver

Em entrevista, o avaliador quer ver se você conecta arquitetura à experiência real do sistema.

Você sobe de nível quando:

• fala de leitura logo após escrita
• diferencia fluxos sensíveis e tolerantes
• propõe estratégia seletiva, não dogma
• lembra que o problema aparece na percepção do usuário

Uma resposta forte costuma soar assim:

“Eu usaria réplica onde o atraso é aceitável, mas protegeria fluxos sensíveis logo após escrita com leitura no primary, afinidade temporária ou outro mecanismo de read-your-own-writes. O objetivo é manter o ganho de réplica sem deixar o produto parecer inconsistente.”

Lag pequeno ainda pode gerar surpresa grande quando aparece no momento errado.

O usuário não reclama de replicação. Ele reclama quando o sistema contradiz a própria confirmação.