Teorema CAP e a arquitetura moderna de sistemas distribuídos

Teorema CAP:

Em sistemas distribuídos, o teorema CAP(Consistency, Availability, Partition Tolerance), afirma que é impossível garantir simultaneamente consistência, disponibilidade e tolerância a partições. Segundo Kepplamann(2017), o “CAP theorem” foi originalmente proposto com objetivo de iniciar uma discussão sobre trade-offs em bancos de dados. Um trade-off refere-se a uma decisão que envolve a troca de uma característica ou benefício em favor de outra. Como os sistemas distribuídos lidam com múltiplas propriedades desejáveis (consistência, disponibilidade e tolerância a partições), é muitas vezes necessário sacrificar uma dessas propriedades para otimizar outra, devido às limitações conforme proposto pelo teorema CAP.

Quem desenvolveu o CAP Theorem:

Eric Brewe conquistou seu Bacharelado em Ciência da Computação em 1984, na UCLA, Berkeley. Concluiu seu PhD no MIT em 1994. Sua tese de doutorado intitulada "Towards Robust Distributed Systems", abordava o design e a construção de sistemas distribuídos robustos e confiáveis. Explorando como tornar sistemas distribuídos mais resistentes a falhas e como garantir que eles possam operar corretamente em face de diferentes tipos de falhas, incluindo falhas de rede e de hardware.

No simpósio sobre Princípios de Computação Distribuída no ano 2000, Eric Brewer fez uma palestra principal sobre sua experiência com as mudanças recentes no desenvolvimento de bancos de dados distribuídos, e como o tamanho dos dados cresceu imensamente, tornando necessário encontrar soluções mais escaláveis do que as bases de dados ACID existentes até então. Como resultado, novos princípios foram desenvolvidos, resumidos sob o paradigma BASE (basicamente disponível, estado suave, consistência eventual).

Para Salomè Simon (2012), o teorema CAP é resultado de uma análise de  Brewer sobre as consequências dessa mudança de paradigma e suas implicações, inclusive na época estava  mais uma intuição pessoal de Brewer do que um fato comprovado. No entanto, o teorema teve um impacto tão grande que muitos pesquisadores começaram a estudar o assunto, e dois anos depois o teorema foi formalmente aprovado.

Temas discutidos na Tese de Brewer: 

Em sistemas distribuídos, o teorema CAP CAP(Consistency, Availability, Partition Tolerance), afirma que é impossível garantir simultaneamente consistência, disponibilidade e tolerância a partições.

Modelos de consistência e como eles se relacionam com a robustez dos sistemas distribuídos.

Desafios em Sistemas Distribuídos, onde ele detalha os desafios práticos enfrentados ao construir sistemas distribuídos e como esses desafios podem ser abordados através de técnicas e design apropriados.

Três propriedades principais que um sistema distribuído pode oferecer, de acordo com o Teorema CAP:

1. Consistência (Consistency): Todos os nós do sistema veem os mesmos dados ao mesmo tempo. Quando uma transação é concluída, todos os usuários ou nós devem ver o mesmo resultado dessa transação.
2. Disponibilidade (Availability): Cada solicitação recebe uma resposta, independentemente de ser um sucesso ou uma falha. O sistema deve estar disponível para responder a consultas e receber atualizações, mesmo se parte do sistema estiver falhando.
3. Tolerância a Partições (Partition Tolerance): O sistema continua a operar corretamente, mesmo quando há uma falha de comunicação ou uma partição de rede que divide o sistema em partes separadas.

De acordo com Brewer, é impossível para um sistema distribuído garantir todas as três propriedades ao mesmo tempo. Ele pode garantir no máximo duas das três:

• CP (Consistency e Partition Tolerance): O sistema garante consistência e tolerância a partições, mas pode sacrificar a disponibilidade. Exemplos incluem sistemas de banco de dados que usam transações e bloqueios para garantir que todos os nós tenham os mesmos dados, mesmo que algumas partes do sistema estejam fora de serviço.
• AP (Availability e Partition Tolerance): O sistema garante disponibilidade e tolerância a partições, mas pode sacrificar a consistência. Exemplos incluem sistemas de banco de dados que permitem leituras de dados desatualizados ou que não garantem que todos os nós tenham os mesmos dados.
• CA (Consistency e Availability): O sistema garante consistência e disponibilidade, mas não tolera partições. Exemplos incluem sistemas centralizados que não são distribuídos, onde a comunicação é contínua e confiável, e não há risco de partições de rede.

A mudança cultural:

Para Martin Kepplamm(2017), antes do teorema CAP, a maioria dos desenvolvedores de bancos de dados distribuídos focava em garantir que todos os dados fossem consistentemente atualizados em todos os servidores, como se eles fossem um único sistema centralizado. Isso funcionava bem em pequenos clusters de máquinas, mas à medida que a internet crescia e os sistemas precisavam escalar para centenas ou milhares de servidores, esse modelo se tornava menos prático.

Com o teorema CAP, surgiu uma nova forma de pensar: é impossível garantir ao mesmo tempo consistência, disponibilidade e tolerância a falhas de rede em sistemas distribuídos. Os engenheiros começaram a explorar novos designs de sistemas que priorizavam um ou outro desses fatores, dependendo das necessidades da aplicação. Por exemplo, alguns sistemas começaram a sacrificar um pouco de consistência para garantir que o sistema continuasse funcionando mesmo que partes da rede falhassem.

Essa mudança cultural abriu espaço para o surgimento de novos tipos de bancos de dados, como os sistemas NoSQL, que são otimizados para diferentes cenários (por exemplo, priorizando disponibilidade e tolerância a falhas em vez de consistência total).

Dependendo das prioridades de um sistema, os engenheiros optam por sacrificar um aspecto para otimizar outro. Por exemplo, Latência vs. Consistência, em sistemas de mensagens ou redes sociais, a latência baixa (tempo de resposta rápido) pode ser mais importante do que garantir que todos os dados sejam consistentes em tempo real. Por exemplo, um usuário pode ver uma postagem alguns segundos antes de ela ser removida, o que é aceitável para manter a experiência fluida.

Sistemas modernos aceitam trade-offs como parte de seu design, priorizando o que é mais importante para as necessidades específicas da aplicação, seja consistência, disponibilidade, desempenho ou outros fatores. Isso permite que os sistemas sejam mais eficientes, escaláveis e adaptáveis às demandas de uso.

Referências:

KEPPLEMANN, M. "Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable". Oreilly, 2017.

SIMON, S. CAP's theorem, 2012.

Google Cloud Platform Live: Fireside Chat with Urs Hölzle, Jeff Dean, and Eric Brewer,Google for developer youtube chanel, 2014.