GH GambleHub

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.

💡 É tratado com aumento do nível de isolamento (para Serializable), bloqueios por predicado, verificações de invariante ou compensações de domínio/abordagem de saga.

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.

Contact

Entrar em contacto

Contacte-nos para qualquer questão ou necessidade de apoio.Estamos sempre prontos para ajudar!

Iniciar integração

O Email é obrigatório. Telegram ou WhatsApp — opcionais.

O seu nome opcional
Email opcional
Assunto opcional
Mensagem opcional
Telegram opcional
@
Se indicar Telegram — responderemos também por lá.
WhatsApp opcional
Formato: +indicativo e número (ex.: +351XXXXXXXXX).

Ao clicar, concorda com o tratamento dos seus dados.