# 📐 Teorema CAP — Material de Estudo
> Calibrado para bancas **AOCP** (IFCE) e **FCC** (TJCE)
> Foco: definições precisas, cenários práticos, assertivas e classificações

---

## 1. Origem e Contexto

O Teorema CAP foi enunciado por **Eric Brewer** em 2000, na conferência PODC (*Principles of Distributed Computing*), sob o título de "Conjectura de Brewer". Em 2002, foi formalmente **provado por Seth Gilbert e Nancy Lynch** (MIT), ganhando o status de teorema.

O teorema surgiu da necessidade de orientar decisões de arquitetura em sistemas distribuídos — especialmente com a explosão de aplicações web em larga escala que exigiam múltiplos servidores e replicação de dados.

---

## 2. Enunciado do Teorema

> **"É impossível para um sistema de armazenamento de dados distribuído garantir simultaneamente as três seguintes propriedades: Consistência, Disponibilidade e Tolerância a Partições. O sistema pode satisfazer, no máximo, duas delas ao mesmo tempo."**

As três propriedades formam o acrônimo **CAP**:

| Letra | Termo original | Tradução |
|---|---|---|
| **C** | Consistency | Consistência |
| **A** | Availability | Disponibilidade |
| **P** | Partition Tolerance | Tolerância a Partições |

---

## 3. Definição de Cada Propriedade

### C — Consistency (Consistência)

Todo nó do sistema distribuído retorna **sempre o valor mais recente** de um dado, ou retorna um erro. Após a confirmação de uma operação de escrita, qualquer leitura subsequente — em qualquer nó — refletirá essa escrita.

- Todos os clientes enxergam **a mesma versão** dos dados ao mesmo tempo
- Se um nó não pode garantir que seu dado está atualizado, ele **retorna erro** em vez de dado desatualizado
- É uma consistência de **visibilidade global entre nós**

Escrita: X = 10 confirmada no Nó 1
              ↓ sincronização
Leitura em qualquer nó → sempre retorna X = 10  ✓

> ⚠️ **Não confundir com a Consistência do ACID:** a consistência do ACID trata da integridade das regras de negócio dentro de uma transação. A consistência do CAP trata da **coerência do estado entre réplicas** de um sistema distribuído. São conceitos distintos e independentes.

---

### A — Availability (Disponibilidade)

Todo pedido feito a um nó **não falho** do sistema recebe uma resposta — seja ela com o dado mais atual ou não. O sistema nunca retorna timeout ou rejeição para requisições válidas.

- O sistema **sempre responde**, mesmo durante partições de rede
- Pode retornar dados ligeiramente desatualizados (*stale data*)
- A ênfase está em **nunca deixar o cliente sem resposta**

Nó 2 não recebeu a última escrita ainda:
Cliente lê X do Nó 2 → recebe X = 8 (desatualizado, mas recebe)  ✓

---

### P — Partition Tolerance (Tolerância a Partições)

O sistema **continua operando** mesmo quando ocorre uma partição de rede — isto é, quando um ou mais nós perdem comunicação com os demais.

- Uma **partição de rede** é a impossibilidade de comunicação entre subconjuntos de nós
- Com P garantido, cada subconjunto continua atendendo requisições independentemente
- **Sem P:** qualquer falha de rede resulta em indisponibilidade total do sistema

[Nó A] ─── X ─── [Nó B]    ← link de rede particionado

Com P → cada nó continua atendendo seus clientes  ✓
Sem P → sistema para até restaurar a comunicação  ✗

> Em sistemas distribuídos reais, partições de rede são **inevitáveis** (falhas de hardware, latência, etc.). Por isso, **P é considerada obrigatória** na prática — o trade-off real é sempre entre C e A.

---

## 4. A Impossibilidade dos Três — Prova Intuitiva

Considere dois nós N1 e N2 com uma partição de rede ativa:

  [N1] ─────X───── [N2]
   ↑                  ↑
Cliente 1          Cliente 2

**Evento:** Cliente 1 escreve `X = 10` em N1. N2 ainda armazena `X = 5`.

**Dilema para N2 ao receber leitura de Cliente 2:**

| Decisão de N2 | Consequência | Propriedade violada |
|---|---|---|
| Responde `X = 5` (valor antigo) | Dado inconsistente entre nós | **C violada** |
| Recusa responder até sincronizar | Sem resposta = indisponível | **A violada** |
| Exige que não haja partição | Sistema frágil a falhas de rede | **P violada** |

**Conclusão:** com uma partição ativa, é matematicamente impossível manter C e A simultaneamente. O sistema deve escolher qual sacrificar.

---

## 5. Os Três Pares de Propriedades

### CP — Consistência + Tolerância a Partições
*(Disponibilidade sacrificada)*

Durante uma partição de rede, o sistema **suspende respostas** a leituras e escritas que não possam ser garantidas como consistentes. Prefere retornar **erro ou timeout** a retornar dado potencialmente desatualizado.

**Características:**
- Alta consistência — dado retornado é sempre o mais recente ou erro
- Durante partições, parte do sistema fica **indisponível**
- Após restauração da rede, sincroniza e retoma operação normal

**Tecnologias típicas:**

| Sistema | Categoria |
|---|---|
| HBase | Banco Wide Column |
| Apache Zookeeper | Coordenação distribuída |
| MongoDB | Banco de documentos (modo padrão) |
| Redis Cluster | Banco Key-Value |
| InfluxDB | Banco de séries temporais |

**Casos de uso ideais:**
- Sistemas bancários e financeiros
- Controle de estoque (evitar overselling)
- Coordenação de processos distribuídos
- Sistemas de votação ou eleição de líderes

---

### AP — Disponibilidade + Tolerância a Partições
*(Consistência sacrificada)*

Durante uma partição de rede, o sistema **continua respondendo** mesmo que os dados retornados possam estar temporariamente desatualizados. Adota o modelo de **consistência eventual** — os nós se sincronizam quando a rede se restabelece.

**Características:**
- Alta disponibilidade — sempre há resposta
- Dados podem estar **temporariamente divergentes** entre nós
- Convergência automática após restabelecimento da comunicação

**Tecnologias típicas:**

| Sistema | Categoria |
|---|---|
| Apache Cassandra | Banco Wide Column |
| Amazon DynamoDB | Banco Key-Value (modo padrão) |
| CouchDB | Banco de documentos |
| Riak | Banco Key-Value |
| DNS | Sistema de nomes distribuído |

**Casos de uso ideais:**
- Redes sociais (timeline de posts)
- Catálogos de produtos em e-commerce
- Sistemas de recomendação
- Métricas e telemetria em tempo real

---

### CA — Consistência + Disponibilidade
*(Tolerância a Partições sacrificada)*

O sistema garante consistência e disponibilidade **enquanto não ocorrem partições de rede**. Se a comunicação entre nós falhar, o sistema para completamente para manter as outras duas propriedades.

**Características:**
- Funciona perfeitamente em **nó único** ou redes altamente confiáveis
- Na prática, aplicável a **SGBDs relacionais tradicionais** sem replicação
- **Não é adequado** para ambientes verdadeiramente distribuídos, onde partições são inevitáveis

**Tecnologias típicas:**

| Sistema | Observação |
|---|---|
| PostgreSQL (instância única) | Sem replicação |
| MySQL (instância única) | Sem replicação |
| Oracle (instância única) | Sem replicação |
| SQL Server (instância única) | Sem replicação |

> **Observação importante:** quando esses SGBDs operam com **replicação**, migram para CP ou AP dependendo da configuração. CA é exclusivo do modelo de nó único.

---

## 6. Diagrama de Posicionamento

               CONSISTENCY (C)
                     △
                    /|\
                   / | \
                  /  |  \
              CP /   |   \ CA
                /    |    \
    HBase      /     |     \  PostgreSQL
    Zookeeper /      |      \  MySQL
    MongoDB  /       ✗       \  (nó único)
            / (impossível    \
           /   C+A+P juntos)  \
          △─────────────────────△
PARTITION (P)                AVAILABILITY (A)
TOLERANCE        AP
                Cassandra
                DynamoDB
                CouchDB

---

## 7. Consistência Eventual

Conceito central dos sistemas **AP**, formalizado por **Werner Vogels** (CTO da Amazon):

> *"Given enough time, all updates will propagate through the system and all the replicas will be consistent."*
> — os dados **convergem** para um estado consistente após um período de tempo, sem garantia de prazo exato.

### Modelos de Consistência (do mais fraco ao mais forte)

| Modelo | Descrição |
|---|---|
| **Eventual Consistency** | Os dados convergem em algum momento futuro não determinado |
| **Causal Consistency** | Operações causalmente relacionadas respeitam ordem causal |
| **Read-your-writes** | O autor sempre lê suas próprias escritas |
| **Monotonic Read** | Uma vez lido um valor V, nunca se lê valor anterior a V |
| **Monotonic Write** | Escritas do mesmo cliente são executadas na ordem enviada |
| **Strong Consistency (Linearizability)** | Equivale ao C do CAP — todos veem a mesma ordem global |

---

## 8. PACELC — Extensão do Teorema CAP

Proposto por **Daniel Abadi** em 2012, o modelo PACELC amplia o CAP ao considerar também o comportamento do sistema **na ausência de partições**:

If    Partition  →  escolha entre  Availability   vs.  Consistency
Else  (normal)   →  escolha entre  Latency        vs.  Consistency

> **Leitura:** "Em caso de Partição, escolha entre A e C; caso contrário (Else), escolha entre Latência e Consistência."

O PACELC reconhece que mesmo sem falhas, sistemas distribuídos enfrentam um trade-off entre **latência de resposta** e **força da consistência**.

### Classificação PACELC de sistemas conhecidos

| Sistema | Com Partição | Sem Partição | Classificação |
|---|---|---|---|
| DynamoDB | AP | EL (baixa latência) | PA/EL |
| Cassandra | AP | EL | PA/EL |
| HBase | CP | EC (consistência forte) | PC/EC |
| Zookeeper | CP | EC | PC/EC |
| MySQL (repl. síncrona) | CP | EC | PC/EC |
| MongoDB | CP | EC | PC/EC |

> **Relação com o CAP:** PACELC é uma **extensão**, não uma substituição. O CAP permanece válido — o PACELC adiciona a dimensão de latência para o caso sem partição.

---

## 9. Aplicação Prática na Escolha de Banco de Dados

| Requisito do sistema | Escolha CAP | Tecnologia sugerida |
|---|---|---|
| Transações financeiras, saldo bancário | CP | HBase, MongoDB |
| Coordenação distribuída, eleição de líder | CP | Zookeeper |
| Timeline de rede social | AP | Cassandra |
| Carrinho de compras em e-commerce | AP | DynamoDB |
| Controle de estoque (sem overselling) | CP | MongoDB, HBase |
| Métricas e logs em tempo real | AP | Cassandra, InfluxDB |
| Sistema legado monolítico | CA | PostgreSQL, MySQL |
| Cache distribuído | AP (em geral) | Redis (modo replicado) |

---

## 10. Classificação Completa dos Principais Bancos NoSQL

| Banco | Modelo de dados | CAP | Consistência padrão |
|---|---|---|---|
| **Cassandra** | Wide Column | AP | Eventual |
| **HBase** | Wide Column | CP | Forte |
| **MongoDB** | Documento | CP | Forte (write concern) |
| **CouchDB** | Documento | AP | Eventual |
| **DynamoDB** | Key-Value | AP (padrão) / CP (opcional) | Eventual (padrão) |
| **Redis** (cluster) | Key-Value | CP | Forte |
| **Riak** | Key-Value | AP | Eventual |
| **Zookeeper** | Coordenação | CP | Forte |
| **Neo4j** | Grafo | CA (nó único) | Forte |
| **InfluxDB** | Série Temporal | CP | Forte |

---

## 11. Questões Estilo AOCP

**Q1 — Cenário prático (estilo AOCP)**

> Uma equipe de desenvolvimento está projetando um sistema de recomendação de produtos para uma plataforma de streaming com milhões de usuários simultâneos. O sistema precisará estar disponível 24/7, mesmo em caso de falhas de comunicação entre data centers. Eventuais inconsistências temporárias nos dados de recomendação são toleráveis, pois não impactam operações críticas. Diante dessas características, qual das classificações do Teorema CAP melhor se aplica ao banco de dados a ser adotado, e qual tecnologia seria mais adequada?

**Resposta:**
O sistema deve ser classificado como **AP (Availability + Partition Tolerance)**, pois prioriza disponibilidade contínua e tolerância a partições, aceitando consistência eventual. A tecnologia mais adequada seria **Apache Cassandra** ou **Amazon DynamoDB**, projetados exatamente para esse perfil de alta disponibilidade e escala horizontal com consistência eventual.

---

**Q2 — Assertivas V/F (estilo AOCP)**

> Sobre o Teorema CAP, julgue as afirmativas:

| # | Afirmativa | Gabarito |
|---|---|---|
| I | O Teorema CAP foi enunciado por Eric Brewer e formalmente provado por Gilbert e Lynch. | ✅ V |
| II | Um sistema classificado como CP pode ficar temporariamente indisponível durante partições de rede para garantir consistência. | ✅ V |
| III | A consistência definida no Teorema CAP é equivalente à consistência do modelo ACID. | ❌ F |
| IV | O Apache Cassandra é um banco de dados classificado como CP, pois prioriza consistência forte. | ❌ F |
| V | Em sistemas AP, os dados eventualmente convergem para um estado consistente após a resolução da partição. | ✅ V |
| VI | Sistemas CA são os mais indicados para ambientes de computação em nuvem com múltiplos data centers. | ❌ F |

---

## 12. Questões Estilo FCC

**Q3 — Definição formal (estilo FCC)**

> Assinale a alternativa que apresenta a definição correta do Teorema CAP:

- A) Um sistema distribuído pode garantir simultaneamente consistência, disponibilidade e tolerância a partições, desde que utilize replicação síncrona.
- B) Em um sistema distribuído, é impossível garantir, ao mesmo tempo, mais de duas das seguintes propriedades: consistência, disponibilidade e tolerância a partições de rede. **(CORRETA)**
- C) A tolerância a partições é opcional em sistemas distribuídos modernos, pois a infraestrutura de nuvem garante comunicação ininterrupta entre nós.
- D) Consistência e disponibilidade são propriedades mutuamente exclusivas em qualquer sistema de banco de dados, distribuído ou não.
- E) O Teorema CAP se aplica exclusivamente a bancos de dados NoSQL, não sendo relevante para sistemas relacionais distribuídos.

---

**Q4 — Classificação (estilo FCC)**

> Considerando o Teorema CAP, associe corretamente os sistemas de gerenciamento de dados à sua classificação:

| Sistema | Classificação |
|---|---|
| Apache Cassandra | ( ) CA   ( ) CP   **(X) AP** |
| Apache HBase | ( ) CA   **(X) CP**   ( ) AP |
| PostgreSQL (instância única) | **(X) CA**   ( ) CP   ( ) AP |
| Apache Zookeeper | ( ) CA   **(X) CP**   ( ) AP |

---

## 13. Resumo Consolidado

| Conceito | Conteúdo |
|---|---|
| **Autor** | Eric Brewer (2000); provado por Gilbert e Lynch (2002) |
| **Regra central** | Máximo 2 das 3 propriedades em sistema distribuído |
| **CP** | Consistente + tolera partição → pode ficar **indisponível** |
| **AP** | Disponível + tolera partição → pode ter dado **desatualizado** |
| **CA** | Consistente + disponível → não tolera **partição** (nó único) |
| **Cassandra** | **AP** — alta disponibilidade, consistência eventual |
| **HBase / Zookeeper** | **CP** — consistência forte, pode ficar indisponível |
| **MongoDB** | **CP** — consistência forte (padrão) |
| **DynamoDB** | **AP** (padrão) — suporta modo CP opcional |
| **PostgreSQL** | **CA** — instância única sem replicação |
| **Consistência eventual** | Característica central de sistemas **AP** |
| **C do CAP ≠ C do ACID** | Conceitos **distintos** — não confundir |
| **PACELC** | Extensão do CAP: adiciona trade-off **Latência vs. Consistência** |
| **P é obrigatório** | Em sistemas distribuídos reais, partições são inevitáveis |