# Teorema CAP e Consistência Eventual

## Monolito *versus* Microsserviços

### Monolito

Fluxo simples e típico de **arquitetura monolítica**. O cliente interage com o sistema de Gestão de Reservas, que centraliza toda a lógica. A verificação de disponibilidade de quartos e o processamento de pagamentos ocorrem em módulos internos do próprio monolito. Não há comunicação remota nem troca de mensagens entre sistemas distintos. Tudo acontece de forma local, síncrona, e todos os módulos acessam o **mesmo banco de dados**.

É o modelo clássico: fácil de entender, fácil de implantar, baixo custo operacional. Funciona bem enquanto o domínio é pequeno e a carga é previsível. O risco está no acoplamento e na escalabilidade futura, mas como ponto de partida — e por décadas foi assim — é sólido.

<figure><img src="https://2751774268-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FxndCEXu1WY8Bo9gAhe4i%2Fuploads%2FltaA6TNpl0c8OylMzOnX%2Fimage.png?alt=media&#x26;token=00e8abf5-ff63-4ed0-96c4-3a92b3bba0f8" alt=""><figcaption></figcaption></figure>

### Microsserviços

Aqui não existe mais monolito. É um **sistema distribuído** com **três serviços independentes**, cada um dono do seu **próprio banco de dados**. A Gestão de Reservas não acessa dados de disponibilidade nem de pagamento diretamente; tudo passa por **chamadas via rede**.

O fluxo lógico fica assim: o cliente aciona o Serviço de Gestão de Reservas, que consulta o Serviço de Disponibilidade de Quartos para verificar vagas e, em seguida, chama o Serviço de Pagamentos para efetivar a cobrança. Cada serviço encapsula sua regra de negócio e sua persistência.

Isso traz isolamento, escalabilidade seletiva e autonomia de evolução — visão moderna e necessária para crescimento.&#x20;

O preço é conhecido:&#x20;

* latência
* falhas de rede
* complexidade operacional
* versionamento de contratos&#x20;
* consistência eventual.&#x20;

Não é evolução automática do monolito, mas outra categoria de problema.

<figure><img src="https://2751774268-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FxndCEXu1WY8Bo9gAhe4i%2Fuploads%2FAG9JetwBNqxEkUJECPsh%2Fimage.png?alt=media&#x26;token=c0e44972-b339-4611-958f-f8a1f33d08d4" alt=""><figcaption></figcaption></figure>

***

## 8 Falácias da Computação Distribuída

1. A rede **não** é confiável
2. A latência **não** é zero
3. A largura de banda **não** é infinita
4. A rede **não** é segura
5. A topologia **muda** constantemente
6. Existem **múltiplos** administradores
7. O custo de transporte **não** é zero
8. A rede **não** é homogênea

***

## Teorema CAP (CAP Theorem)

O **Teorema CAP** afirma que, em um **sistema distribuído**, é impossível garantir **simultaneamente**:

* **C – Consistência**: todos os nós veem os mesmos dados ao mesmo tempo.
* **A – Disponibilidade**: toda requisição recebe uma resposta válida.
* **P – Tolerância a Partições**: o sistema continua operando mesmo com falhas de rede.

Os blocos empilhados representam exatamente isso:&#x20;

> **Só é possível escolher dois vértices por vez**

Quando ocorre uma partição de rede (e ela sempre ocorre), o sistema é forçado a **abrir mão de C ou de A**.&#x20;

> **Não existe “CAP completo”**

Na prática:

* **CP**: prefere consistência, aceita indisponibilidade temporária.
* **AP**: prefere disponibilidade, aceita dados temporariamente inconsistentes.
* **CA**: só funciona enquanto não há partição — ou seja, **fora da realidade distribuída**.

É um limite físico, não uma escolha de framework. Entender isso evita arquiteturas fantasiosas e decisões erradas no início.

<figure><img src="https://2751774268-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FxndCEXu1WY8Bo9gAhe4i%2Fuploads%2F7bz1el55Fe37KxDTxVct%2Fimage.png?alt=media&#x26;token=cab82571-4912-4088-b44a-22a43bcf6785" alt=""><figcaption></figcaption></figure>

O diagrama representa o **Teorema CAP** por meio de **blocos empilhados verticalmente**, com **Consistência (C)** no topo, **Disponibilidade (A)** no meio e **Tolerância a Partições (P)** na base.

A disposição evidencia a limitação fundamental dos sistemas distribuídos:&#x20;

> **A tolerância a partições é inevitável!**

Diante de uma falha de rede, o sistema precisa **escolher entre manter a consistência ou a disponibilidade**. Não é possível garantir as três propriedades ao mesmo tempo.

A representação elimina a falsa ideia de escolha livre e reforça a realidade prática:&#x20;

> CAP é sobre decisão e concessão, não sobre equilíbrio perfeito.

***

## P - Partition Tolerance: A Realidade Inescapável

### **Análise**

* Partições de rede são **inevitáveis** em sistemas distribuídos
* Microsserviços equivalem a múltiplos serviços que também equivalem a múltiplos pontos de falha
* Tolerância a partições (P) é **obrigatória** em arquiteturas de microsserviços
* Operações não podem depender de comunicação perfeita

<figure><img src="https://2751774268-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FxndCEXu1WY8Bo9gAhe4i%2Fuploads%2FwITVmoshr1ZlFl2oKjLD%2Fimage.png?alt=media&#x26;token=12e8ad9e-60a3-4acf-b0a6-42b3dcc42c6a" alt=""><figcaption></figcaption></figure>

Falha de rede na comunicação entre o Serviço de Gestão de Reservas e o Serviço de Disponibilidade de Quartos.

***

## O Trade-off Fundamental: CP *versus* AP

### Opção 1: CP (Consistency + Partition Tolerance)

<figure><img src="https://2751774268-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FxndCEXu1WY8Bo9gAhe4i%2Fuploads%2Fz7wKQX4LKUAF1Zjkjbkq%2Fimage.png?alt=media&#x26;token=ea3b3fbf-4a84-490f-a4d2-aa07886b2942" alt=""><figcaption></figcaption></figure>

#### **Comportamento CP**

* Prioriza **consistência** sobre disponibilidade
* Se o serviço de Disponibilidade está inacessível:
  * A Gestão de Reservas **bloqueia** a operação
  * Fica aguardando até que a comunicação seja restabelecida
  * Cliente espera ou recebe timeout/erro

#### **Vantagem**

* Garante que não haja risco de *overbooking*&#x20;

#### **Desvantagem**

* Indisponibilidade do sistema durante partições

<figure><img src="https://2751774268-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FxndCEXu1WY8Bo9gAhe4i%2Fuploads%2FhB2lk0Xu5FjvWgu1EK9w%2Fimage.png?alt=media&#x26;token=1f591908-acbc-4141-9fa7-5c15e9489160" alt=""><figcaption></figcaption></figure>

Diagrama de cliente que cria reserva no Serviço de Gestão de Reservas que tenta checar disponibilidade no Serviço de Disponibilidade de Quartos, mas ocorre falha na comunicação.

***

### Opção 2: AP (Availability + Partition Tolerance)

<figure><img src="https://2751774268-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FxndCEXu1WY8Bo9gAhe4i%2Fuploads%2FaXBvE3KTp1PBp9GqdnET%2Fimage.png?alt=media&#x26;token=59637c7a-8f30-4f64-a09c-84a18fc010ca" alt=""><figcaption></figcaption></figure>

#### **Comportamento AP**

* Prioriza **disponibilidade** sobre consistência
* A Gestão de Reservas armazena localmente a informação de disponibilidade
* Aceita reserva baseada na **última informação conhecida**
* Continua funcionando mesmo durante partições

#### **Vantagem**

* Alta disponibilidade do sistema&#x20;

#### **Desvantagem**

* Risco de *overbooking* (inconsistência temporária)

<figure><img src="https://2751774268-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FxndCEXu1WY8Bo9gAhe4i%2Fuploads%2F2FsLwtaymx9wbB1L2jJq%2Fimage.png?alt=media&#x26;token=f09fecc9-5a25-4f79-98be-fd0cfb09a49d" alt=""><figcaption></figcaption></figure>

Diagrama de dois serviços com seus próprios bancos. Serviço de Gestão de Reservas mostra "Quarto 1: Disponível", Serviço de Disponibilidade de Quartos também mostra "Quarto 1: Disponível".

***

## Consistência Eventual

### **Definição**

* Sistema eventualmente converge para estado consistente
* Período de inconsistência entre replicação/sincronização
* Aceitável em muitos cenários de negócio

### **Mecanismos de Implementação**

* Replicação assíncrona entre serviços
* Mensageria (Kafka, RabbitMQ) para eventos de domínio
* *Sagas* para transações distribuídas
* *CDC* (Change Data Capture) para sincronização

<figure><img src="https://2751774268-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FxndCEXu1WY8Bo9gAhe4i%2Fuploads%2FuAY9LAgPxqN9c7CczpHO%2Fimage.png?alt=media&#x26;token=43740992-5a35-4959-b01b-75b7db3069a3" alt=""><figcaption></figcaption></figure>

Dados inconsistentes entre os dois serviços. Na Gestão de Reservas: "Quarto 1: RESERVADO". Na Disponibilidade de Quartos: "Quarto 1: DISPONÍVEL".

### Implicações Práticas

#### **Para desenvolvedores Java/Spring**

```java
// Exemplo: Serviço usando consistência eventual com Spring Cloud Stream
@Service
public class ReservationService {
    @Autowired
    private StreamBridge streamBridge;
    
    public void createReservation(ReservationRequest request) {
        // 1. Salva localmente com estado "pendente"
        reservationRepository.save(request);
        
        // 2. Publica evento para sincronização eventual
        streamBridge.send("availability-events", 
            new AvailabilityUpdatedEvent(request.getRoomId(), "RESERVED"));
        
        // 3. Continua processamento mesmo se sincronização falhar
    }
}
```

#### **Padrões relevantes**

* *Saga Pattern* para transações distribuídas
* *CQRS* para separação de leitura/escrita
* *Event Sourcing* para reconstrução de estado
* *API Composition* para queries entre serviços

***

## Considerações Finais

* Teorema CAP é uma **"lei da natureza"** em sistemas distribuídos
* Microsserviços **necessariamente** operam no trade-off CP *versus* AP
* Escolha depende dos requisitos de negócio:
  * **CP**: Sistemas financeiros, controle de estoque crítico
  * **AP**: Redes sociais, catálogos de produtos, sistemas de recomendação
* Consistência eventual requer:
  * Design cuidadoso de *idempotency*
  * Mecanismos de reconciliação
  * Monitoramento de latência de consistência
  * Comunicação clara com stakeholders sobre trade-offs

***

## Perguntas para Discussão

1. No cenário de hotelaria, qual abordagem (CP ou AP) é mais apropriada?
2. Como medir e definir SLAs para latência de consistência?
3. Quais ferramentas Java/Spring facilitam implementação de consistência eventual?
4. Como testar cenários de partição de rede em ambientes de desenvolvimento?
5. Qual o impacto da escolha CP vs AP na experiência do usuário final?
