CAP theorem na prática

O problema

CAP theorem vira slogan muito rápido.

Muita gente cita. Pouca gente explica.

A frase mais famosa e:

“Você só pode ter dois de tres.”

O problema e que isso quase não ajuda.

Se você leu essa frase e continuou sem entender, o problema não e você.

Ela pula direto para o slogan antes de mostrar a situacao real que o teorema tenta explicar.

Modelo mental

CAP fala do que acontece quando um sistema distribuido sofre uma falha de rede.

Pensa em dois lados do sistema que continuam no ar, mas deixam de conversar direito.

Exemplo simples:

• duas regiões deixam de se enxergar
• um banco principal e uma replica perdem comunicação
• dois nos continuam vivos, mas não conseguem confirmar estado entre si

Quando isso acontece, voce perde o conforto de assumir que os dois lados vao responder com a mesma verdade.

E e aqui que CAP entra.

O que você realmente precisa escolher

Os tres termos sao estes:

• C de consistência: eu só respondo quando consigo manter uma visão coerente do dado
• A de disponibilidade: eu continuo respondendo mesmo durante a falha
• P de partition tolerance: o sistema continua existindo mesmo com falha de rede entre partes dele

A parte que mais confunde e esta:

em sistema distribuido, P não e luxo. A rede pode falhar goste você ou não.

Entao a escolha pratica nao costuma ser “quais dois de tres eu quero no dia feliz”.

A escolha prática costuma ser:

• eu prefiro segurar resposta para proteger consistência?
• ou prefiro continuar respondendo, mesmo aceitando dado velho ou comportamento temporariamente divergente?

Quebrando o problema

Quando faz sentido esperar

Alguns fluxos nao toleram mentira.

Exemplos:

• saldo
• limite de crédito
• coordenação de lider
• lock distribuido

Se a rede quebrou e você não consegue confirmar o estado direito, talvez seja melhor parar, esperar ou devolver erro temporário.

Aqui a dor e indisponibilidade temporária.

Mas essa troca pode valer a pena porque responder com dado errado custa caro demais.

Quando faz sentido continuar respondendo

Outros fluxos toleram atraso melhor do que silencio.

Exemplos:

• feed
• contagem de likes
• recomendação
• ranking não crítico

Se uma parte do sistema continuar respondendo com dado um pouco velho por alguns segundos, isso pode ser aceitavel.

Aqui a dor e inconsistência temporária.

Mas essa troca pode valer a pena porque o produto nao some da frente do usuario.

Só depois vale falar em CP e AP

Se alguém usar os termos CP e AP, agora fica mais simples:

• CP: diante da falha, o sistema puxa mais para consistência
• AP: diante da falha, o sistema puxa mais para disponibilidade

Mas isso ja e rotulo. O importante vem antes.

Exemplo concreto

Imagine uma rede social.

Um usuário publica um post. Alguns seguidores em outra região ainda não veem o post por alguns segundos.

Isso normalmente e aceitavel. O sistema continua respondendo e o estado converge depois.

Agora imagina saldo bancario ou controle de um job crítico.

Se dois lados do sistema não conseguem se falar, talvez seja melhor segurar resposta do que correr o risco de dois estados conflitarem.

Perceba o ponto:

• no feed, atraso pequeno costuma ser toleravel
• no saldo ou na coordenação crítica, atraso pode ser menos grave do que resposta errada

CAP nao escolhe por voce.

Quem escolhe e o tipo de erro que o negócio aceita durante a falha.

O que CAP não explica

CAP não serve para explicar qualquer caso de dado velho.

As vezes o problema e:

• cache mal invalidado
• replica com lag
• leitura feita na região errada
• pipeline assíncrono mal desenhado

Ou seja:

• nem todo dado velho e CAP
• nem todo problema de consistência pede esse teorema

CAP e uma lente para comportamento sob falha de rede em sistema distribuido.

Erros comuns de leitura

• Repetir “dois de tres” sem mencionar partição.
• Falar como se P fosse opcional.
• Usar CP e AP antes de explicar o problema concreto.
• Achar que CAP explica todo caso de dado velho.
• Tratar CAP como medalha de arquitetura, não como decisão de comportamento sob falha.

Como isso aparece em entrevista

Em entrevista, uma resposta boa costuma soar assim:

“Se a rede falhar aqui, eu prefiro travar esse fluxo para proteger consistência ou continuar respondendo mesmo com chance de atraso?”

Isso e muito melhor do que soltar “dois de tres” e esperar que pareca profundo.

O entrevistador quer ver se você:

• entendeu o que e partição em linguagem humana
• conecta consistência e disponibilidade ao fluxo real
• não usa o termo como decoração

Fechando

CAP fica muito mais claro quando você troca a pergunta.

Em vez de perguntar:

“Quais dois de tres eu escolho?”

pergunte:

“Quando a rede quebrar, eu prefiro esperar pelo dado certo ou continuar respondendo com risco de atraso?”

Essa e a parte do CAP que realmente importa.