Consistência forte vs eventual

O problema

“Consistência eventual” virou desculpa para muita coisa mal desenhada.

Quando o sistema mostra informação errada, contraditória ou atrasada em momento crítico, alguém aparece para dizer que “isso é eventual consistency”.

Nem sempre é.

Às vezes é só cache mal invalidado, réplica atrasada ou um fluxo mal desenhado tentando se esconder atrás de um nome bonito.

Modelo mental

Antes de falar de definição, vale pensar em duas cenas simples.

Cena 1:

• eu troco a foto de perfil e abro a página logo depois
• se eu ainda vejo a foto antiga, parece que a ação falhou

Cena 2:

• eu dou like em um post e a contagem global demora alguns segundos para subir
• isso normalmente não destrói a experiência

Essas duas cenas mostram a pergunta certa:

o que o usuário ainda pode ver de estranho depois da escrita?

Consistência é isso.

Quebrando o problema

O que significa consistência forte

Em linguagem simples:

• a escrita foi confirmada
• a leitura relevante seguinte já enxerga o estado novo

Isso costuma fazer sentido quando ver dado velho é caro demais.

Exemplos:

• saldo
• limite de crédito
• reserva de inventário muito apertada
• eleição de líder

O ganho é previsibilidade.

O custo costuma aparecer em latência, disponibilidade ou complexidade maior de coordenação.

O que significa consistência eventual

Também em linguagem simples:

• a escrita foi aceita
• mas algumas leituras ainda podem ver o valor antigo por um tempo

Eventual não significa bagunça.

Significa convergir depois, não necessariamente agora.

Exemplos aceitáveis:

• contagem de likes
• feed
• recomendação
• ranking

Nesses casos, atraso pequeno normalmente é tolerável.

Read-your-own-writes

Essa garantia significa: se eu acabei de escrever um dado, eu mesmo consigo ler o resultado da minha escrita.

Isso resolve muita dor prática.

Mesmo que o resto do sistema ainda esteja convergindo, pelo menos o próprio autor não vê a própria ação “sumindo”.

Em produto real, isso muda muito a sensação de confiança.

Uma garantia extra que evita sensação estranha

Outra ideia útil é monotonic reads.

Ela evita que o usuário veja o tempo andar para trás.

Se ele já viu uma versão nova, não deveria voltar para uma mais velha logo depois.

De onde as inconsistências costumam vir

Na prática, o problema raramente nasce do termo abstrato.

Ele nasce do mecanismo:

• leitura em réplica com lag
• cache que não foi invalidado
• leitura em região diferente da escrita
• pipeline assíncrono que atualiza partes do estado em momentos diferentes

Isso importa porque a mitigação muda. Às vezes você precisa de escrita síncrona. Às vezes só precisa garantir read-your-own-writes para o próprio usuário. Às vezes basta deixar claro no produto que a contagem converge depois.

Como decidir sem virar debate abstrato

A pergunta mais útil não é:

“qual modelo e mais sofisticado?”

E esta:

qual anomalia o negócio aceita que o usuário veja?

Se a resposta é “nenhuma nesse fluxo”, consistência mais forte entra na conversa.

Se a resposta é “algum atraso pequeno e aceitável”, consistência eventual pode ser boa troca.

Exemplo simples

Imagina três casos.

1. O usuário troca a foto de perfil e abre a página logo depois. Se ele ainda ver a foto antiga, isso parece erro. Aqui, read-your-own-writes ajuda muito.

2. O like demora alguns segundos para refletir na contagem global. Isso costuma ser aceitável. O usuário talvez nem perceba.

3. O usuário faz uma transferência e vê saldo antigo em momento crítico. Aqui o atraso deixa de ser detalhe e vira risco real.

O mesmo sistema pode até misturar garantias diferentes dependendo do fluxo.

E isso costuma ser mais maduro do que querer consistência forte para tudo.

Erros comuns

• Chamar todo dado velho de eventual consistency.
• Tratar consistência eventual como bug tolerado por preguiça.
• Falar de consistência sem falar de impacto no usuário.
• Ignorar garantias intermediárias.
• Discutir o tema só em termos de banco e esquecer cache, réplica e leitura em região diferente.

Como um senior pensa nisso

Quem tem mais experiência costuma sair rápido da definição abstrata e ir para a anomalia visível.

O raciocínio fica parecido com:

“Se a leitura vier atrasada aqui, o que exatamente o usuário vai perceber? Isso e aceitavel, irritante ou perigoso?”

Esse jeito de pensar melhora muito a conversa porque conecta arquitetura ao comportamento do produto.

Maturidade aqui é não tratar consistência forte como medalha e consistência eventual como gambiarra.

São ferramentas para tipos diferentes de risco.

O que o entrevistador quer ver

Em entrevista, consistência fica forte quando você:

• explica a diferença entre forte e eventual em linguagem simples
• mostra que entendeu o impacto da leitura atrasada
• conhece garantias intermediárias úteis
• escolhe o modelo pelo efeito no negócio

Consistência não é uma medalha técnica. É uma decisão sobre quanta surpresa o seu sistema aceita produzir para o usuário.