Modelos de coerência
A coerência descreve os valores e a ordem que os leitores veem nas mudanças competitivas. A escolha correta do modelo é o equilíbrio entre o rigor dos invariantes, a latência, a disponibilidade e o custo (PACELC). A seguir, um guia prático sobre modelos e suas aplicações.
1) Modelos «rigorosos»
Linearizable (lineável, Strong)
É como se todas as operações tivessem sido executadas instantaneamente em uma ordem unificada, respeitando o tempo real.
Os benefícios são um modelo mental simples, seguro para dinheiro e exclusividade.
Contras: quórum/líder → crescimento p95/p99, especialmente interregional.
Balanços, inventários com limites rígidos, nomes únicos/chaves.
Sequential consistency
Todos os fluxos veem a mesma ordem de transação, mas não a ordem real-tempo é obrigatória. Pouco mais fraco que linearizable, raramente exposto diretamente nos produtos.
Serializable (serialidade transacional)
Equivale a uma ordem consistente de transações (em vez de transações individuais).
Os benefícios são a correção de invariantes complexos no nível de consultas/tabelas.
Contras: mais caro (bloqueio/versionização/validação de conflitos).
Yuskees, finoperações complexas, contagens consistentes, inventário.
Snapshot Isolation (SI)
Cada transação lê uma foto invariável no tempo; os registros são conflitantes em «linhas idênticas», mas é possível write skew.
Os benefícios são leituras rápidas sem bloqueios, relatórios estáveis.
Contras: Não seriado, armadilha write skew (exemplo: médicos de serviço).
Euskees: analistas, relatórios, a maioria CRUD sem invariantes severos.
2) Por-sessão e garantias de causa
Read-Your-Writes (RYW)
O cliente vê-a sempre nas leituras seguintes.
Vantagens: ótimo UX (formulário → confirmação).
Contras: garantia local, não global.
Monotonic Reads / Writes
As leituras não são «reversíveis»; os registros de um único cliente são aplicados na mesma ordem de envio.
Causal Consistency (causal)
Se a operação depender de outra (A → B), todos veem A antes de B.
Os benefícios são intuitivos para os Sz-Fids, os comentários.
Contras: mais difícil de rotação e rótulos de causalidade (relógios vetores).
Yuskees: comunicações, edição compartilhada, fitas de eventos.
3) Modelos fracos e híbridos
Bounded Staleness
As leituras podem ficar para trás, no máximo, nas versões N' ou N.
Os benefícios são um UX previsível, um bom compromisso interregional.
Contras: Não protege contra conflitos de gravação.
Eventual Consistency
Com o tempo, todas as cópias convergem; ordem e atraso não estão garantidos.
Benefícios: latência mínima/custo, alta disponibilidade (AP).
Contras: precisa de merge explícito (CRDT/regras de domínio).
Os cascos, os fidos, as métricas, os «likes», os guias críticos.
4) Anomalias típicas e o que elas significam
Dirty Read: leitura de dados não contábeis.
Read não-repeatable: A mesma leitura dentro de uma transação oferece valores diferentes.
Phantom: Ao ser solicitado novamente, aparece/desaparece a linha que corresponde ao predicado.
Write Skew (SE): Duas transações leem um invariante que se cruza e gravam linhas diferentes, violando a condição «deve ser ≥ 1».
Lost Update: a gravação «apaga» as alterações do concorrente.
5) Quórum e níveis de leitura/escrita
Muitos armazenamentos permitem definir os níveis de 'R '/' W' (número de réplicas para leitura/escrita).
O quórum (R + W> N) oferece «interseção» e fortes garantias de leitura do último registro.
W = 1, R = 1 → atraso baixo, mas pode haver dados antigos.
Sintonizando: Operações críticas a alta 'W' (ou líder), e as outras a baixa 'R' para velocidade.
Read-repair/Hinted handoff ajudam a obter coerência no fundo.
6) Relógio e ordem: como «compreendemos» a causalidade
Lamport clocks: ordem parcial de eventos.
Vector clocks: detectam a causalidade, permitem a detecção de conflitos.
Abordagens Hybrid/TruTime: limitam a divisão de horas em um cluster para organizar transações e bound-staleness.
Versioning: 'versão/ts + ator' para merge; em CRDT - semiprupção fechada (comutação/idempotidade).
7) CRDT e domínio merge
O CRDT (Tipos de Dados Convergentes/Replicáveis) garante a fusão sem coordenação: G-Counter, OR-Set, LWW-Register, Map, OTS/WOOT.
Quando útil, «likes», muitas marcas, cestas, documentos.
Limitações: inventar uma semântica correta de «fusão» para uma entidade específica de domínio.
8) Comunicação com CAP/PACELC
Modelos rígidos (Linearizable/Serializable) em uma região multi-t → a COP com aumento de latência (PACELC: escolha C e pagamos L).
Modelos fracos/híbridos → AP e/ou baixo L, mas precisa de merge/conflito-ressalva.
Híbrido: Núcleo de CP para invariantes + projeções AP/cachês para leitura.
9) Seleção de modelo: folha de cheque
1. Invariantes, o que não pode ser quebrado? (exclusividade, equilíbrio, limites).
2. Regionalidade: onde são feitas as gravações/leituras? (local/global).
3. SLO de latência: p95/p99 para caminhos críticos?
4. Preço da coordenação: está disposto a pagar quórum interregional?
5. Conflitos: Há merge determinado ou precisa de um coordenador?
6. Espera UX: RYW/monotonic/causal é importante para o cliente?
7. Observabilidade: em que mede a liga/conflitante/grau de obsolescência?
8. Folbacks: O que acontece quando a rede é dividida (P)? read-only/gravação local/filas?
10) Receitas rápidas
Pagamento/balanço: Linearizable/Serializable, líder + quórum, curtas horas; leituras de RYW.
Perfis/fid: Causal/Bounded staleness + dinheiro; CRDT para likes/contadores; RYW para o autor.
Pesquisa/analista: SI/Read Committed, projeções asinhrônicas, eventual para índices.
SaaS global: Geo-partitioning; «Registros domésticos» - COP, relatórios/diretórios - AP.
Edição compartilhada: causa/eventual + CRDT/OT; salvar a «história».
11) Observabilidade da coerência
Lag métricas: 'reprodução _ lag', 'estaleness _ age _ ms' (p50/p95/p99).
Conflito: proporção de conflitos, tempo médio de resolução.
Quórum: sucesso de 'R/W' quórum, temporais de rotas interregionais.
Garantia de Cliente: RYW/monotonic - rótulos por sessão.
12) Erros típicos
Exigir Strong «em todos os lugares» sem base de negócios → explosão de latidão e custo.
Dual-write para diferentes regiões sem sagas/CRDT → fantasmas e perda de invariantes.
Ignorar RYW/monotonicidade em UX → «desaparecer» dados recém-enviados.
Não monitorar a obsolescência do dinheiro/projeção → divergências «eternas».
Merge não pensado → perda inesperada/duplicação de valores.
13) Mini-referência arquitetura
Write-core (COP): líder, quórum, SLO e times, revistas.
Read-plane (AP): visualizações materializadas, cachês TTL, read-repair.
Cliente: sticky-sessions/garantias de sessão (RYW/monotonic), rótulos de versão.
Conflito-motor: regras de domínio CRDT, fila de resolução manual.
Monitorização, conflitos, leituras obsoletas.
Conclusão
O modelo de coerência é um contrato de engenharia entre dados, atraso e disponibilidade. Comece com invariantes e SLO, escolha rigorosamente onde você quiser e mais fraco onde você pode, sem esquecer as garantias de clientes, quórum, relógio e observabilidade. Uma combinação adequada de modelos oferece escala, previsibilidade e sustentabilidade - sem sacrificar a verdade empresarial e a confiança do usuário.