Teorema CAP, não chame seu banco de dados de CP ou AP e vamos continuar conversando sobre consistência e disponibilidade. Vamos lá! Eu quero continuar essa conversa com você para destacar que, como já estamos falando nas últimas aulas, estamos falando nas últimas aulas, disponibilidade no CAP é definida como cada solicitação recebida por um nó sem falha, ou seja, sem falha de banco de dados, deve resultar em uma resposta sem erro para o nosso sistema, para o nosso aplicativo. Então, vamos continuar aqui comigo e com o Kleffman, principalmente, nesse ponto de vista, que é bem interessante. Não é suficiente que algum desses nós seja capaz de lidar com a solicitação. É necessário que qualquer nó que não apresente falha seja capaz de lidar com essa requisição. seja capaz de lidar com essa requisição. Porém, na prática, nós vamos perceber que muitos sistemas que estão no mercado como altamente disponíveis, na verdade, não atendem a essa definição de disponibilidade. Vamos ilustrar isso aqui. Primeiro, replicação, pensando nesse cenário hipotético que nós temos dois locais físicos, dois data centers, sejam privados ou de nuvem pública. Na replicação, sempre que os dados forem gravados no data center número 1, também precisam ser gravados noacenter número 2, que tem réplicas deste banco de dados. E nós vamos ter na prática um grupo de usuários sendo atendidos pelo datacenter número 1, que aqui eu grafei em azul, e vamos ter um outro grupo de usuários sendo atendidos pelo Data Center 2, que eu grafei em laranja. E com certeza, neste ciclo de vida de operação, em algum momento vai acontecer, por uma razão desconhecida, não mapeada, imprevista, o particionamento de rede, que é a interrupção de comunicação entre estes dois nós de bancos de dados que temos aqui. Pois bem, quando isso acontecer, existem duas possíveis escolhas. Se nós permitirmos que o aplicativo continue tendo permissão de escrita nos bancos de dados, em ambos os data centers, nós vamos ter uma violação da linearizabilidade ou da linearização da nossa consistência. Então, para não perder a linearização, as leituras e escritas podem e precisam ocorrer em um único data center. No outro data center, que não pode ser atualizado devido à falha naquele link de rede, o banco de dados deveria parar de aceitar leituras e gravações até que a partição de rede seja reparada e que o sincronismo, ou seja, a replicação entre os bancos, esteja restabelecido. Então, com este exemplo, o que nós vamos tirar de conclusão? Primeiro, embora o banco de dados não tenha falhado, ele não pode processar as solicitações. Então, não está disponível para o conceito CAP. Mas, caso o nosso sistema, nosso aplicativo, escolha pela consistência forte da linearização, isso não significa necessariamente que a partição de rede leva automaticamente a uma interrupção do aplicativo. Porque se nós rotearmos aquele grupo laranja de usuários para o data center número 1, isso continua com disponibilidade para a aplicação. O que isso significa, no final de contas? Que a nossa disponibilidade na vida real é um conceito diferente de disponibilidade no Teorema CAP. Então, este ponto é muito importante, por isso que eu estou insistindo nestas aulas sobre o Teorema CAP, para que você fique bem preparado para perceber estes tópicos nas discussões nas quais você certamente vai participar na sua empresa na hora de optar por um banco do tipo 1 ou do tipo 2 e certamente CAP vai aparecer como um critério de decisão fique muito atento porque disponibilidade na vida real não é a disponibilidade do CAP e também como já vimos, consistência ácida também não significa consistência aqui no Teorema CAP. Ou seja, precisamos conhecer muito bem o requisito da aplicação com a qual estamos trabalhando para conseguir tomar uma decisão adequada.