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.

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.

O preço é conhecido:

• latência

• falhas de rede

• complexidade operacional

• versionamento de contratos

• consistência eventual.

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

---

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:

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.

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.

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:

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:

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

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)

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

Desvantagem

• Indisponibilidade do sistema durante partições

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)

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

Desvantagem

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

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

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

// 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?