CAp e compromissos de engenharia

O CAP afirma que, com a divisão da rede (Partition, P), o sistema distribuído não pode garantir simultaneamente uma forte coerência (Consistency, C) e disponibilidade (Availability, A). Se você tiver um P, você deve selecionar um COP ou um AP. Se não houver separação, a restrição não é válida, mas há outros compromissos, principalmente o atraso (latency) e o custo.

A engenharia prática vai além do CAP: importante PACELC (se P - escolher C ou A; de outra forma, escolhemos entre Latency e Consistency), modelos de coerência, SLA/SLO, yuskees e riscos empresariais.

1) Definições básicas (sem filosofia)

Coerência (C): Todos os clientes veem o mesmo resultado como se as operações tivessem sido executadas em sequência (lineabilidade/strong consistency).
Disponibilidade (A): Cada solicitação de um nó que não está disponível é concluída com uma resposta em um tempo razoável, mesmo quando dividido.
Divisão (P): perda ou grande degradação da ligação entre os nódulos/clusters regionais; basicamente, «inevitável» em grande escala.
PACELC: em P, selecionamos C ou A; else (quando P não) selecionamos L (baixa) ou C (forte coerência).

2) Imagem intuitiva de seleção

COP (coerência mais importante): Ao separar algumas solicitações, rejeitamos/bloqueamos para não perturbar os invariantes. Adequado para dinheiro, transações, contabilidade de restos.
AP (a disponibilidade é mais importante): respondemos sempre, mas permitimos o descumprimento temporário, depois contraímos os conflitos (CRDT/regras de merja). Adequado para sots-fids, contadores de likes, perfis de cajado.
CA (simultaneamente C e A): Só é possível na ausência de P - ou seja, enquanto a rede estiver saudável. Em operação real, «CA» é um estado temporário, não uma propriedade de design.

3) PACELC: não nos esquecemos do atraso

• Forte consistência entre as regiões = quórum intercontinental de dezenas a centenas de ms para p95.
• Leituras locais (baixo L) = garantias mais fracas (read-my-writes, bounded staleness, eventual).
• O PACELC ajuda a explicar por que é «rápido e rigoroso» global - raro: a luz não é instantânea e os quóruns crescem com a dobrabilidade da rede.

4) Modelos de coerência (espectro rápido)

Linearizable/Strong: Como se fosse uma ordem sequencial.
Serializável: equivale a uma ordem consistente de transações (acima do nível de registros).
Read-your-writes/Monotonic reads: o cliente após a sua própria gravação lê o novo valor.
Bounded staleness: As leituras não estão mais atrasadas do que as versões N/Se.
Evolucional consistency: Com o tempo, todas as cópias convergem; os conflitos têm de ser resolvidos.

5) Pattern COP e AP em produtos e protocolos (conceitualmente)

Abordagens de CD: revistas/liderança quórum (Raft/Paxos), transações rigorosas, localizações globais de líder, replicação sincronizada. O preço é a rejeição de parte dos pedidos de P e o aumento dos atrasos.
Abordagens AP: multi-master/multi-líder, CRDT, distribuição gossip, replicação assíncrona, resolução de conflitos (LWW, relógio vetorial, funções de domínio). Preço - concordância temporária e complexidade das regras de domínio.

6) Compromissos na região multi

Líder Global: Uma lógica simples, mas as regiões «distantes» pagam latência; P - bloqueio de gravações.
Líderes locais + asinharão (AP): gravação rápida localmente, seguida de replicação; mudanças conflitantes exigem merj.
Geo-partitioning: os dados «vivem» mais perto do usuário/jurisdição; A Região Cruzada é só uma unidade.
O dual-write é proibido sem sagas/CRDT: caso contrário, os fantasmas e os débitos duplos são permitidos.

7) Engenharia invariantes e soluções de negócios

Primeiro invariantes: O que nunca pode ser quebrado (consumo duplo, saldo negativo, exclusividade da chave) e o que «experimenta» (contagem de visualizações, recomendações).

• Invariante «rígido» de COP para as operações apropriadas.
• Invariante «suave» → AP seguido de contração.

8) Técnicas de mitigação de compromissos

Cash e CQRS: Leituras em dinheiro/projeção próximo (AP), gravações em registro rigoroso (COP).
RPO/RTO como linguagem de compromisso: quantos dados podem ser perdidos (RPO) e como recuperar rapidamente (RTO).
ID e relógio alinhados: temporizadores monótonos (abordagens Hybrid/TruTime), ULID/Snowflake.
Sags/TSS - Compensações de negócios em vez de bloqueios globais.
CRDT e domínio para coleções, contadores, «vitórias recentes».
Bounded staleness: Equilíbrio UX e precisão.

9) Observabilidade, SLO e gerenciamento de incidentes

SLO por latência (p50/p95/p99) separadamente para leituras/registros e regiões.
SLO em disponibilidade com base no feelover da região.
Lag Repliced/Conflitante: proporção de conflitos, tempo médio de resolução.
Alertas por P, aumento de temporizações de canais interregionais, aumento de erros de quórum.
Planos Degrade: modo read-only, serviço local seguido de merj, desativação de funções «caras».

10) Folha de cheque de seleção de estratégia

1. Que invariantes não podem ser quebrados? O que permite o eventual?
2. Precisamos de uma gravação regional cruzada com baixa latência?
3. Quais são as metas SLO (latência/disponibilidade) e custo (egress/replicação)?
4. Permite o manual merge ou apenas a máquina (CRDT/regras)?
5. Qual é o perfil de falha da rede: frequência, duração, blast radius?
6. Existe uma localização legal de dados (residency)?
7. Que modelo de coerência é aceitável para cada tipo de dados/operação?
8. Como é que vão ver, lagos, conflitos, quórum?
9. O que faz o sistema no P: bloquear, degradar, separar o tráfego?
10. Qual o plano de recuperação e repatriação de dados após P?

11) Erros típicos

Perseguir «CA para sempre». A primeira P terá de escolher, melhor com antecedência.
Um multi master global sem regras de merja. Os conflitos «comem» os dados e a confiança.
Uma forte consistência em todo o lado. Os quóruns em excesso atingem p95/p99 e o orçamento.
Dual-write sem transações/sagas. Invariantes e fantasmas perdidos.
Ignorar PACELC. Em tempos de paz, a latência sofre, a tempestade, a disponibilidade.
Telemetria zero de conflitos e lajes. Os problemas são visíveis apenas para o usuário.

12) Receitas rápidas

Pagamento/balanço: Armazenamento COP com quórum; gravações apenas através do líder; leituras podem ser armazenadas, mas em UX crítico - read-your-writes.
Conteúdo/FID: Replicação AP + CRDT/regras de merja; P - servir localmente, depois contrair.
SaaS global: geo-partitioning por 'tenant/region'; operações rigorosas em uma região «doméstica» (COP), relatórios/buscas, através de projeções asincrônicas (AP).
Sinalização Real Tempo: Anycast/edge + pneu AP; comandos críticos passam pelo canal confirmado (COP).
Auditoria/registro: única fonte de verdade (append-only) com garantias COP, em torno de cachês e projeções.

13) Mini-referência arquitetura (verbal)

Write-core (COP): líder + replicação quórum, invariantes rígidos, sagas para efeitos entre servidores.
Read-plane (AP): visualizações materializadas, cachês, índices de search, atualização asincrona.
Geo-roting: os usuários vão para a região «doméstica»; P - modo local + posterior replicação.
Conflito-motor: CRDT/regras; registro de conflitos e soluções manuais.
Observabilidade: trailing de quórum, lajes, mapa de incidentes da rede.

14) Matemática prática de atrasos (simples avaliação)

Óptica ≈ 5 ms por 1000 km (RPT ainda maior). Quórum intercontinental p95 fácil> 150-250 ms.
Qualquer «Strong global» para gravar é um pedido caro. Se o UX requer <100-150 ms, pense nos efeitos locais write-home + asinhrônicos.

15) Políticas de separação

Caminho COP: bloquear gravações fora do quórum; incluir o read-only; dar estatais honestas ao usuário.
Caminho AP: atender localmente; marcar versões; durante a recuperação, um merj determinado; conflitos para a fila de análise.

Conclusão

O CAP não é um dogma, mas um lembrete: as divisões da rede são inevitáveis, e o projeto deve escolher previamente o que doar para a tempestade - disponibilidade ou coerência rigorosa. O PACELC adiciona um eixo-chave de atraso em tempo claro. Combine estratégias: mantenha o núcleo COP onde os invariantes são sagrados e o plano AP onde a velocidade e a resistência são mais importantes. Coloque telemetria, planos de degradação e processos de merja - e o sistema preserva os dados e a confiança do usuário.