Teorema de Brewer (CAP)

O teorema CAP descoberto por Eric Brewer, foi apresentado pela primeira vês a 19 de Julho de 2000, quarta-feira, no simpósio da ACM intitulado "Principles of Distributed Computing" .

Este teorema resultou de um extenso trabalho de observação do comportamento dos sistemas da Inktomi e veio a revolucionar a arquitectura de sistemas de grande escala.

Nomeadamente a arquitectura dos sistemas da Amazon, eBay e Twitter entre muitas outras.

Mas afinal o que é o teorema de Brewer?

Brewer identificou 3 requisitos sistémicos fundamentais que se influenciam mutuamente no desenho e instalação de sistemas distribuídos.

Estes são: Consistência, Disponibilidade e Tolerância a Quebras - "Consistency, Availability, Partition Tolerance" ou CAP.

Consistência

Um sistema é consistente se não gerar resultados contraditórios entre si tendo como base a lógica de negócio implementada.

Por exemplo, partindo do princípio que aplicação foi testada e a lógica implementada está correcta um sistema consistente garante que:

• o mesmo livro nunca será endereçado para dois clientes distintos em simultâneo;
• um contrato de seguros não será realizado com um cliente com elevado grau de sinistralidade;
• um cliente nunca pagará mais ou menos do que o valor em factura;
• nunca serão dadas ordens de pagamento em duplicado;
• um cliente não pode pagar com VISA um valor assima do seu plafond;
• entre muitos outros cenários e regras que poderíamos enumerar.

Disponibilidade

Um sistema está disponível sempre que dá resposta ás solicitações dos seus utilizadores, e indisponível caso contrário.

Por exemplo, quando se submete um contracto de seguros quer-se que o sistema responda e que não dê uma mensagem do tipo "time-out" ou "sistema indisponível".

Um sistema pode ser mais ou menos disponível num período de tempo. No entanto num determinado momento T está ou não está disponível.

Tolerância a Quebras

Uma quebra no sistema é a falha de um componente ou ligação entre componentes da solução.

Por exemplo se a nossa aplicação está distribuída por múltiplos "tiers" ou nós numa rede informática, uma quebra pode ser o servidor desligar-se, o router bloquear ou um cabo de rede partir-se e deixar de funcionar.

Como é óbvio nesta configuração a probabilidade haver quebras nas ligações entre os componentes da solução é elevada quando comparada com uma solução de máquina única.

Um sistema é tolerante a quebras se nada menos do que a falha total da rede formada pelos seus componentes o leve a deixar de funcionar correctamente.

A Revelação de Brewer

A revelação de Brewer é que não é possível que um sistema informático preencha estes 3 requisitos em simultâneo. Mante-los e escalando o sistema ao mesmo tempo por forma a dar conta do aumento de actividade, torna-se cada vês mais dispendioso atingindo um ponto de impossibilidade técnica com impacto directo na disponibilidade.

Quantos de nós em grandes empresas já ouvimos dizer, o sistema está lento, está indisponível ou "está em baixo" durante minutos e em alguns casos horas?

Acabo assim com estas duas questões. 10 anos depois ...

• É este teorema significativo para os departamentos de IT das grandes empresas em PT, nomeadamente na forma como o negócio é gerido electrónicamente?
• Qual é o seu significado técnico para os departamentos de IT de hoje em PT?