Porque em sistemas distribuídos, a tolerância a partição é praticamente obrigatória?
Porque em sistemas distribuídos você não controla totalmente a rede.
Quando seu sistema roda em várias máquinas, regiões, pods, bancos ou serviços diferentes, eles precisam se comunicar pela rede. E rede falha. Pode acontecer:
- uma instância não conseguir falar com outra;
- um banco ficar isolado temporariamente;
- uma região da cloud perder comunicação com outra;
- latência aumentar muito;
- pacotes serem perdidos;
- DNS, load balancer ou roteamento falharem;
- um nó estar vivo, mas inacessível para parte do sistema.
Isso é uma partição de rede: o sistema não caiu completamente, mas algumas partes dele não conseguem se comunicar entre si.
Então, em sistemas distribuídos, Partition Tolerance é praticamente obrigatória porque você precisa assumir que a rede pode falhar a qualquer momento. Não é uma questão de “se vai acontecer”, mas de “quando vai acontecer”.
O ponto principal do CAP é:
Quando acontece uma partição de rede, o sistema precisa escolher entre manter consistência ou manter disponibilidade.
Exemplo simples:
Imagine dois servidores:
Servidor A ───── Servidor B
Agora a rede entre eles falha:
Servidor A X Servidor B
Se os dois continuam aceitando escrita sem se comunicar, você ganha Availability, mas pode perder Consistency, porque cada lado pode ter uma versão diferente dos dados.
Se o sistema bloqueia uma das partes até a comunicação voltar, você preserva Consistency, mas perde Availability, porque algumas requisições vão falhar ou ficar indisponíveis.
Por isso, na prática, em sistemas distribuídos, você não escolhe entre C, A e P como se pudesse ignorar o P. O P já vem no pacote. A escolha real geralmente é:
Durante uma partição, meu sistema prefere CP ou AP?
CP: prefere consistência.
Bom para dinheiro, transações, estoque crítico, pedidos, saldo bancário.
AP: prefere disponibilidade.
Bom para likes, views, feed, cache, métricas, notificações, dados que podem sincronizar depois.