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?