Strong Consistency: quando necessário

Strong Consistency é um modelo em que todas as operações parecem ser executadas de forma instantânea e consistente em uma ordem global alinhada com o tempo real. O usuário lê o último valor confirmado e os dois clientes paralelos não se superam logicamente.

A coerência rigorosa fornece um modelo mental simples e protege os invariantes rígidos, mas requer coordenação (quórum/líder), o que aumenta o atraso e a sensibilidade às divisões de rede.

1) Quando Strong - obrigatório

Finanças e cálculos

«Duplo desperdício» é inadmissível.
Transferências e intercorrências: o mesmo valor não pode ser feito duas vezes.

Inventário e limites

Saldos de mercadoria/local no hotel/bilhete: não pode sair para valores negativos.
Limites de transação por unidade de tempo (limites de crédito, API).

Exclusividade e integridade

Logins/identificadores/regras de dedução exclusivos.
Invariantes no nível de domínio: «O médico deve estar de serviço na sala», «Não é possível fazer fila> N tarefas ativas».

Auditorias e registros imutáveis

Eventos que servem de fonte legal da verdade, ordem e cumplicidade são críticos.

Se uma violação do invariante envolve um risco de negócio inaceitável (perda de dinheiro, sanções, perda de confiança) - escolha Strong Consistency.

2) O que é «rigoroso»

Linearizability (nível operacional): a leitura mostra a gravação mais recente; os tempos são respeitados.
Serializável (nível transacional): o resultado equivale a transações em sequência (pode ser strong, mas às vezes implementado sem ordem real-time rígida).
A diferença importante é que o Serializable protege contra anomalias de nível de transação (phantom/write-skew) e o Linearizable sobre instantaneidade e ordem de operações individuais. Muitas vezes você precisa de ambas as propriedades (por exemplo, dinheiro em banco de dados + registro de eventos).

3) Preço do rigor: PACELC e CAP

PACELC: Ao dividir uma rede (P), você deve escolher C (rigor) ou A (disponibilidade). Strong → COP: É melhor recusar ou bloquear do que perturbar o invariante. Quando não há separação (EL), pagamos L - coordenação/quórum cresce p95/p99.
Prática: strong para «núcleo de invariantes», em torno de projeções rápidas/cachês com eventual para não sofrer UX.

4) Como o Strong Consistency atinge

Liderança e quórum

O único líder aceita as gravações; leituras para líder ou quórum de réplicas.
Quórum 'W' para gravar e 'R' para ler com 'R + W> N' aumenta as chances de ler 'último'.

Algoritmos de concordância

Raft/Pajos: logos de replicação, confirmação da maioria, termo/índice.
Replicação sincronizada: a gravação só é confirmada após a persistência no quórum.

Horário e ordem

TrueTime/Hybrid Logical Clocks (HLC): Limitar o relógio para uma seriada global segura.
Fence-tokens/versioning: proteção contra líderes «matutinos» e split-brain.

Isolar transações

Serializável (SI + verificação de conflitos/looks de predicado): proteção contra phantom/write-skew.
Strict-serializable: serialidade + lineabilidade em relação ao tempo real.

5) Região multi: opções e compromissos

Líder Global (COP)

As gravações passam por uma região líder; leituras - cachês/projeções locais ou através do líder.
Os benefícios são um modelo simples. Contras: p95/PTT para líder, e P para bloqueio de gravações.

Líderes regionais + quórum sincronizado

Quórum georasirênico de várias regiões; cada entrada aguarda confirmações> 50%.
Os benefícios, sem um pescoço apertado, alta resistência. Contras, latência intercontinental.

Geo-partitioning

Dados «domésticos» para a região (tenante/jurisdição); transações globais através de sagas/unidades.
Vantagens: atrasos baixos para gravações locais. Contras: planejamento de limites de dados.

6) Configuração de R/W e leitura

Gravações: 'W = majority' - padrão para strong.

• «O mais recente» é 'R = majority' ou leitura no líder.
• Para reduzir o L - leitura «stale-ok» de réplicas para telas secundárias (com marcação explícita em UX).
• Read-repair/lease read: otimização sem perda de rigor nas locações curtas do líder.

7) Desempenho e UX

Latitude: Direcione-se para a RPT entre o cliente e o líder/quórum (interregionalmente centenas de ms).
Pattern «write-strong, read-fast»: strong na gravação + dinheiro/projeções em leitura, com RYW para o autor.
Batch/pacotes: agrupe os registros, mas siga a latência de cauda.
Contornos de degradação - no incidente - read-only, estatais honestas, proibição de mutações perigosas.

8) Observabilidade da Via Estricial

Métricas

p50/p95/p99 latency: quórum write, quórum read, leituras de liderança.
Quórum bem sucedido, repetições/reversões, mudança de líder.
Liga de replicação (esperado pequeno, mas obrigatório).
Proporção de leituras «estale» (se incluído).

Training

Spans: «aceitação pelo líder», «replicação», «comitência do quórum».
Теги: `term`, `leader_id`, `quorum_size`, `region`.

Alertas

Crescimento p95/p99, reeleição frequente do líder, quorum-timeouts, split-brain indicadores.

9) Testes e caos

Jepsen-similares: separações de rede, atrasos, drops, clock-skew.
Invariantes safety: impossibilidade de duplo desperdício/saldo negativo/reserva dupla.
Liderança: renúncia do líder, reeleição sob carga, fence-tokens.
Coerência de leitura: a leitura imediatamente após a gravação deve ver «novo» (RYW/linearizable read).

10) Playbooks incidentes

Perda de quórum: mudar para read-only, avisar os clientes, enviar a gravação para a região «doméstica» se houver geo-partioning.
O aumento do laticínio é interregional: reduzir temporariamente o volume de registros rigorosos (migrar parte dos fluxos para filas/projeções), localizar o tráfego.
Flap Líder: Aumentar os horários das eleições, verificar as redes/a deriva do relógio/pausas GC.
Split-brain: ativar fence-tokens/lease-verificação, parar os antigos líderes ao nível da operadora.

11) Erros típicos

Exigir Strong «em todos os lugares», uma explosão de latência e custo em vez de focar nos invariantes.
Tentar ser CA em divisões reais: no momento P, o sistema ainda faz escolhas, muitas vezes de forma implícita.
Dual-write para diferentes regiões sem sagas/coordenador: fantasmas e perda de invariantes.
Ausência de RYW: O usuário não vê a sua entidade recém-gravada - queda de confiança.
Ignorar o relógio: sem HLC/TruTime-limite é fácil obter um tempo e corrida «saltitante».
Sem plano de degradação, o P tem falhas parciais caóticas.

12) Soluções rápidas (receitas)

Pagamentos/balanços: líder + maior-quórum; transações estrict-serializable; tempo curto, falha severa em P.
Reservas (lugares/slots): write-strong através do líder, leitura em dinheiro com RYW; TTL + TCC.
SaaS global: geo-partition por 'tenant/region'; operações rigorosas na região doméstica, relatórios/buscas - através de projeções.
Diário/auditoria: Revista append-only CP; as leituras podem ser cantadas, mas as leituras podem ser creditadas por pontos de controle.

13) Folha de cheque antes de vender

• Foram emitidos invariantes que exigem strong; o resto está em RC/projecção.
• Modo selecionado: líder único/quórum interregional/geo-partition.
• Configurados 'W = majority', 'R = líder' majority 'para caminhos críticos.
• Fornecidos com RYW/monotonic para UX; estão claramente marcados «stale-ok» de leitura.
• As métricas de quórum, lajes, latências estão incluídas; alertas para p95/p99 e reeleição.
• Há um plano degrade: read-only, desativação de mutações perigosas, filas para «depois da tempestade».
• Testes de caos: separação, clock-skew, falha do líder; foram testados os invariantes safety.
• Documentação dos contratos: o que é rigoroso, o que «pode ficar para trás», comunicação para o produto/suporte.

Conclusão

Strong Consistency é um instrumento de defesa da verdade onde o erro é inaceitável. Use-a pontualmente em torno de invariantes severos, pagando conscientemente para coordenar a latência e a disponibilidade nas tempestades. Combinar o núcleo de CD para leitura crítica, PA e projeção para velocidade. Com a telemetria correta, a degradação e os testes, você vai manter a correção e a experiência do usuário.