Explique o teorema CAP e como ele se aplicou a um sistema em que você trabalhou.

CAP diz que, quando uma partição de rede separa seus nós, você tem que escolher entre consistência e disponibilidade. Você não pode abrir mão de tolerância a partição, porque redes falham quer você planeje ou não. Então a pergunta real é o que seu sistema faz durante uma partição: recusar escritas para continuar correto, ou aceitá-las e reconciliar depois. Fora de uma partição você pode ter as duas, e é por isso que latência é a troca do dia a dia.

O enquadramento que eu uso é que tolerância a partição não é escolha, porque pacotes são descartados e switches falham independentemente da minha arquitetura. Então o CAP na verdade pergunta o que o sistema faz enquanto está partido: recusar a escrita para ninguém ler dado velho, ou aceitar a escrita e resolver depois. O que eu gosto na extensão PACELC é que ela nomeia a parte com que você lida todo dia, que é que mesmo com tudo saudável você está trocando latência por consistência, porque uma escrita com quórum entre regiões custa round trips. Num produto em que trabalhei a gente dividiu por funcionalidade. Qualquer coisa tocando cobrança passava pelo primário com garantia de leitura após escrita, porque cobrar alguém duas vezes não se resolve com um pedido de desculpas. O feed de atividade lia de réplicas e podia estar alguns segundos atrás, e ninguém nunca percebeu. Mesmo sistema, duas respostas, escolhidas por funcionalidade e não como religião arquitetural.