Consistência Eventual Avançada — CRDTs, vector clocks, causalidade e garantias de sessão

Em 2008, Werner Vogels — CTO da Amazon — publicou um artigo no ACM Queue com o título "Eventually Consistent". O artigo começava com uma provocação: a propriedade ACID que todos aprendemos na faculdade, em particular a consistência, tinha um custo enorme em disponibilidade e latência em sistemas distribuídos. A Amazon tinha aprendido isso da forma difícil. O carrinho de compras, um dos sistemas mais críticos, precisava funcionar sempre — mesmo durante partições de rede, mesmo com servidores offline, mesmo durante picos de 10× o tráfego normal. Isso era impossível com consistência forte. A solução era aceitar que dois nós poderiam ter versões diferentes do carrinho ao mesmo tempo, e definir uma regra de convergência: "se dois nós têm versões diferentes do carrinho, a versão final é a união de ambos — nunca perdemos um item." Isso é eventual consistency com semântica de domínio bem definida.

O artigo de Vogels introduziu um vocabulário que ainda usamos: garantias de sessão — contratos entre o sistema e o cliente individual que tornam eventual consistency utilizável. Read-your-writes, monotonic reads, writes follow reads, monotonic writes. Esses contratos não são "eventual consistency vs strong consistency" — são propriedades ortogonais que podem ser combinadas. Um sistema pode ser eventualmente consistente globalmente mas garantir read-your-writes por sessão. Entender esses contratos é o que separa "usou Cassandra e ficou com dados inconsistentes sem entender por quê" de "usou Cassandra sabendo exatamente que garantias cada operação tem, e designou o sistema para que as anomalias possíveis fossem aceitáveis pelo produto".

O espectro de consistência

Consistência não é binária. Existe um espectro de modelos, cada um com tradeoffs de performance, disponibilidade e complexidade de raciocínio para o developer.

# Do mais forte (mais caro) ao mais fraco (mais performático):

# 1. LINEARIZABILITY (Strict Consistency)
# Definição: cada operação parece ser executada atomicamente num ponto único no tempo.
# Todo read retorna o valor do write mais recente globalmente.
# Equivalente a um sistema de processo único.
# Implementação: consenso (Raft, Paxos) ou single-threaded sequencial
# Custo: toda operação precisa coordenar com maioria dos nós
# Latência: ~2× RTT inter-nó mínimo (propose + ack)
# Quem oferece: etcd, ZooKeeper, CockroachDB (por chave), Spanner

# 2. SEQUENTIAL CONSISTENCY (Lamport, 1979)
# Definição: existe uma ordem global das operações que é consistente com
# a ordem de cada processo individualmente — mas pode não refletir tempo real.
# Dois processos podem ver writes em ordens diferentes, desde que cada um
# veja todos os writes de cada processo em ordem.
# Custo: menor que linearizability; não precisa de timestamp de tempo real
# Quem oferece: alguns bancos com total ordering mas sem real-time guarantees

# 3. CAUSAL CONSISTENCY
# Definição: operações causalmente relacionadas são vistas na mesma ordem
# por todos os nós. Operações concorrentes (sem relação causal) podem ser
# vistas em qualquer ordem.
# A → B (A causou B): todos os nós veem A antes de B
# A ∥ B (A e B concorrentes): diferentes nós podem ver A antes de B ou B antes de A
# Custo: rastrear causalidade (vector clocks) mas sem coordenação global
# Quem oferece: COPS, Eiger, alguns sistemas acadêmicos; MongoDB com certas configs

# 4. PRAM / FIFO CONSISTENCY (Pipeline RAM)
# Definição: writes de um único processo são vistos em ordem por todos os outros.
# Writes de processos diferentes podem chegar em qualquer ordem a cada observer.
# Custo: muito baixo; requer apenas ordering por fonte
# Uso: logs de replicação, Kafka (ordering por partition + producer ID)

# 5. EVENTUAL CONSISTENCY
# Definição: se não houver novos writes, eventualmente todos os nós convergem
# para o mesmo valor. SEM garantias sobre ordem ou timing.
# Subtipos (importantes para entender contratos específicos):
#   - Strong eventual: convergência garantida após receber os mesmos updates
#     (mesmo que em ordem diferente) → CRDTs
#   - Weak eventual: convergência possível, mas pode precisar de resolução manual

# 6. SESSION GUARANTEES (ortogonais ao espectro acima)
# Aplicadas por sessão/cliente; NÃO são modelos globais do sistema
# Read Your Writes (RYW): você sempre vê seus próprios writes
# Monotonic Reads (MR): se você leu valor V, futuras leituras retornam V ou mais recente
# Writes Follow Reads (WFR): writes propagam após reads na mesma sessão
# Monotonic Writes (MW): seus writes são aplicados na ordem que você os fez

# Comparação prática de latência (sistema 3 DCs, ~100ms inter-DC RTT):
# Linearizability:     ~200ms (round-trip para quorum global)
# Sequential:          ~200ms (similar, coordenação necessária)
# Causal:              ~1ms  (local write + tag; sem espera)
# Eventual:            <1ms  (local write; fire-and-forget)
# Eventual + RYW:      <1ms  local; reads do mesmo nó que escreveu

Happens-before e relógios lógicos de Lamport

Para raciocinar sobre causalidade em sistemas distribuídos sem um relógio global, Leslie Lamport definiu em 1978 a relação happens-before (→). É a fundação matemática de tudo que discutiremos depois.

# Definição happens-before (Lamport, 1978):
# A → B se:
#   1. A e B são eventos no mesmo processo e A ocorre antes de B (program order)
#   2. A é o envio de uma mensagem e B é o recebimento dessa mensagem
#   3. (Transitividade) Existe C tal que A → C e C → B

# Eventos são CONCORRENTES (A ∥ B) se NÃO (A → B) E NÃO (B → A)
# Causalidade ≠ tempo real: se A → B, A causou (ou poderia ter causado) B.
# Concorrência ≠ simultâneo: significa que nenhum dos dois causou o outro.

# RELÓGIO LÓGICO DE LAMPORT:
# Cada processo P tem um contador C(P), inicialmente 0.
# Regras:
#   - Antes de cada evento local: C(P)++
#   - Ao enviar mensagem: incluir C(P) na mensagem
#   - Ao receber mensagem com timestamp T: C(P) = max(C(P), T) + 1

# Propriedade: se A → B, então C(A) < C(B)
# LIMITAÇÃO: o inverso NÃO é verdadeiro!
#   C(A) < C(B) NÃO implica A → B (podem ser concorrentes)
#   Lamport clocks não distinguem concorrência de causalidade

# Exemplo:
# P1:  evento a (C=1) → envia msg para P2 (C=1 na msg)
# P2:  recebe msg (C = max(0,1)+1 = 2) → evento b (C=3)
# P3:  evento c (C=1) — CONCORRENTE com tudo em P1 e P2
#
# a → b (causal; msg transmitiu causalidade)
# c ∥ a e c ∥ b (P3 não tem conexão causal com P1/P2)
# Mas C(c)=1 < C(b)=3, e isso não significa c → b

# POR QUE ISSO IMPORTA:
# Em bancos distribuídos, timestamps de sistema (wall clock) são usados para
# Last Write Wins (LWW). Mas relógios de sistema driftam (Network Time Protocol
# tem precisão de ~100ms; em sistemas de alta taxa isso é catastrófico).
# Dois writes "simultâneos" com diferentes wall clocks podem ordenar incorretamente.
# Amazon DynamoDB original usava vector clocks para evitar esse problema.
# CassandraDB usa timestamps de cliente (timestamps do processo que escreveu) com LWW
# — é por isso que relógios desajustados em Cassandra perdem dados silenciosamente.

Vector clocks: capturando causalidade com precisão

Vector clocks resolvem a limitação dos relógios de Lamport: com eles, é possível determinar se dois eventos são causalmente relacionados ou concorrentes. Cada nó rastreia um vetor de contadores — um por participante no sistema.

# VECTOR CLOCK:
# Sistema com N processos. Cada processo Pi mantém V[i], um vetor de N inteiros.
# V[i][j] = "quantos eventos de Pj o processo Pi conhece"

# Regras:
#   - Evento local em Pi: V[i][i]++
#   - Enviar mensagem de Pi: incluir V[i] na mensagem
#   - Receber mensagem de Pj com vetor Vm em Pi:
#       V[i][k] = max(V[i][k], Vm[k]) para todo k
#       V[i][i]++  (evento de recebimento conta como evento local)

# Comparação entre vector clocks:
# V ≤ V' se V[k] ≤ V'[k] para todo k (V "aconteceu antes" ou igual)
# V < V' se V ≤ V' e V ≠ V'   (V happened-before V')
# CONCORRENTE se NÃO (V ≤ V') e NÃO (V' ≤ V)

# Exemplo (3 processos A, B, C):
# Estado inicial: A=[0,0,0], B=[0,0,0], C=[0,0,0]
#
# A grava X=1:   A=[1,0,0]
# A envia para B: mensagem carrega [1,0,0]
# B recebe:      B=[1,1,0] (max([0,0,0],[1,0,0]) + B incrementa próprio)
# B grava Y=2:   B=[1,2,0]
#
# C grava Z=3:   C=[0,0,1]  (CONCORRENTE — C não sabe nada de A ou B ainda)
#
# B envia para C: mensagem carrega [1,2,0]
# C recebe:      C=[1,2,2]  (max([0,0,1],[1,2,0]) = [1,2,1] + C incrementa)
#
# Comparações:
# A=[1,0,0] < B=[1,2,0]: A → B (A causou B, via mensagem)  ✓
# C=[0,0,1] ∥ A=[1,0,0]: C e A são concorrentes (nenhum causou o outro) ✓
# C=[0,0,1] ∥ B=[1,2,0]: C e B são concorrentes (antes de B enviar para C) ✓
# C=[1,2,2] > B=[1,2,0]: B → C (B causou o C final, via mensagem) ✓

# CUSTO DOS VECTOR CLOCKS:
# O vetor cresce com o número de participantes.
# Para sistema com N participantes: O(N) espaço por evento e por mensagem.
# Em sistemas com milhares de nós, isso se torna proibitivo.
# Solução 1: plausible clocks (truncar após K eventos mais recentes)
# Solução 2: dot notation (Riak) — versão compacta dos vector clocks
# Solução 3: CRDTs que não precisam de vector clocks para convergir

# RIAK E DYNAMO:
# Riak usava vector clocks explícitos; migrou para "dotted version vectors" em 2014
# — mais compactos e sem o problema de "sibling explosion"
# DynamoDB original usava vector clocks; migrou para LWW com timestamps
# — tradeoff: simplicidade vs precisão de causalidade

# CASSANDRA:
# Não usa vector clocks. Usa timestamps de cliente (write timestamp).
# LWW: write com maior timestamp vence.
# Consequência: se dois writes chegam com o mesmo timestamp, um é perdido
# silenciosamente (baseado em ordering de bytes do valor).
# Consequência crítica: clock skew entre clientes = perda de dados.

Conflitos e estratégias de resolução

# Quando dois writes concorrentes (sem relação happens-before) chegam ao mesmo nó,
# o sistema precisa decidir o que fazer. Opções:

# 1. LAST WRITE WINS (LWW)
# Usar o write com maior timestamp. O outro é descartado.
# Implementação: cada write carrega um timestamp; ao merge, mantém o maior.
# Vantagem: trivialmente simples; sem conflito visível para a aplicação
# Desvantagem: PERDE DADOS SILENCIOSAMENTE.
#   Alice adiciona produto A no carrinho (t=100).
#   Bob (sessão diferente) remove produto B do carrinho (t=101).
#   LWW: Bob "vence" e o estado é o carrinho sem B, MAS sem A também.
#   Se o write de Bob não incluía o produto A (escreveu estado parcial),
#   o produto A é perdido sem nenhum erro.
# Quem usa: Cassandra (timestamp de cliente), muitos bancos em modo "eventual"
# Mitigação: usar timestamps de alta resolução (UUID v1, Snowflake ID) e
#   escrever sempre o objeto completo (não deltas parciais)

# 2. MULTI-VALUE (Siblings)
# Preservar ambos os valores concorrentes; expor o conflito para a aplicação.
# Implementação: ao detectar versões concorrentes (vector clock comparison),
#   armazenar ambas como "siblings". A aplicação resolve.
# Vantagem: zero perda de dados; a aplicação decide a semântica correta
# Desvantagem: a aplicação PRECISA lidar com conflitos (overhead de dev)
# Quem usa: Riak (siblings explícitos), DynamoDB original (versões concorrentes)
# Exemplo Dynamo shopping cart:
#   Duas versões concorrentes do carrinho → merge = UNIÃO dos itens
#   Possível ter duplicatas (item adicionado por ambos): remove duplicatas

# 3. MERGE CUSTOMIZADO (domain-specific)
# Definir uma função de merge que sempre converge e respeita semântica do domínio.
# Exemplo 1 — contador de likes: merge = soma dos deltas (não o valor atual)
# Exemplo 2 — carrinho: merge = união dos conjuntos de itens
# Exemplo 3 — documento colaborativo: merge = algoritmo OT ou CRDT de texto
# Vantagem: preserva dados + semântica correta do produto
# Desvantagem: requer design cuidadoso por tipo de dado
# Isso é a essência dos CRDTs: estruturas de dados onde merge é sempre definido
# e associativo/comutativo/idempotente

# 4. CONFLICT AVOIDANCE (sharding por entidade)
# Em vez de conflitos, garantir que só UM nó processa writes para cada entidade.
# Single-writer per entity: usuário X sempre escreve no shard S.
# Vantagem: zero conflitos por design; consistência forte por entidade
# Desvantagem: hotspot se entidade é popular; failover precisa reatribuição
# Quem usa: Kafka (partition ownership), Redis Cluster (hash slot ownership)

CRDTs: estruturas que convergem por design

CRDT (Conflict-free Replicated Data Type) é uma estrutura de dados projetada matematicamente para que qualquer conjunto de updates, aplicados em qualquer ordem, produza o mesmo resultado final. Não há conflitos porque a semântica é definida para não ter. São a base de Google Docs, Figma, e qualquer editor colaborativo moderno.

# Propriedades matemáticas de um CRDT (CvRDT — state-based):
# A operação merge deve ser:
#   - Comutativa: merge(A, B) = merge(B, A)  (ordem não importa)
#   - Associativa: merge(A, merge(B, C)) = merge(merge(A, B), C)
#   - Idempotente: merge(A, A) = A  (aplicar duas vezes = uma vez)
# Se merge satisfaz essas propriedades, o sistema converge automaticamente.

# G-COUNTER (Grow-Only Counter):
# Problema: contar eventos em sistema distribuído sem coordinator.
# Estrutura: cada nó i tem um contador local C[i]
# Increment: C[myNodeId]++  (apenas meu próprio counter)
# Value: sum(C[i] for all i)
# Merge: max(C[i], C'[i]) element-wise

class GCounter:
    def __init__(self, node_id, num_nodes):
        self.node_id = node_id
        self.counters = [0] * num_nodes  # um counter por nó

    def increment(self):
        self.counters[self.node_id] += 1

    def value(self):
        return sum(self.counters)

    def merge(self, other):
        # Merge: max element-wise (comutativo, associativo, idempotente)
        merged = GCounter(self.node_id, len(self.counters))
        merged.counters = [max(a, b) for a, b in zip(self.counters, other.counters)]
        return merged

# Exemplo:
# Node A: [3, 0, 0] (incrementou 3x)
# Node B: [0, 5, 0] (incrementou 5x)
# Node C: [0, 0, 2] (incrementou 2x)
# Merge de A e B: [3, 5, 0], valor = 8
# Merge final:   [3, 5, 2], valor = 10  ← valor correto global

# PN-COUNTER (Positive-Negative Counter — para incremento e decremento):
# Dois G-Counters: P (incrementos) e N (decrementos)
# Value: P.value() - N.value()
# Merge: merge P e N separadamente

# LWW-REGISTER (Last Write Wins Register):
# Estrutura: (value, timestamp)
# Merge: o par com maior timestamp vence
# Propriedades: comutativo e associativo MAS resolve conflito por timestamp
# Problema: se dois writes têm mesmo timestamp exato, é não-determinístico
# Solução: usar timestamp de alta precisão + node ID como desempate

# OR-SET (Observed-Remove Set — conjunto com add/remove):
# O desafio: em conjunto distribuído, como garantir que remove desfaz add?
# Problema clássico: A adiciona X (timestamp T1); B remove X (sem saber de T1).
# Se B remove "todo X", remove o X que A adicionou — perda de dado.
# OR-Set solução: cada ADD cria uma tag única. REMOVE remove tags específicas.
# Add "maçã" → cria tag (maçã, uuid4())
# Remove "maçã" → remove TODAS as tags de "maçã" que o nó CONHECE
# Se o add de A ainda não chegou em B quando B fez remove → a tag de A persiste!
# Quando B finalmente recebe o add de A → tag existe, maçã está no set

class ORSet:
    def __init__(self):
        self.elements = {}  # element → set of tags

    def add(self, element, unique_tag=None):
        import uuid
        tag = unique_tag or str(uuid.uuid4())
        if element not in self.elements:
            self.elements[element] = set()
        self.elements[element].add(tag)
        return tag

    def remove(self, element):
        # Remove todas as tags conhecidas (observadas) para este elemento
        if element in self.elements:
            del self.elements[element]

    def contains(self, element):
        return element in self.elements and len(self.elements[element]) > 0

    def merge(self, other):
        result = ORSet()
        all_elements = set(self.elements) | set(other.elements)
        for e in all_elements:
            my_tags = self.elements.get(e, set())
            other_tags = other.elements.get(e, set())
            merged_tags = my_tags | other_tags  # união das tags
            if merged_tags:
                result.elements[e] = merged_tags
        return result
# Semântica: add-wins (se há conflito simultâneo add+remove, add vence)
# Por quê: a tag do add persiste; o remove só elimina tags que já conhecia

# MV-REGISTER (Multi-Value Register — o "carrinho" do Dynamo):
# Armazena múltiplos valores concorrentes como "siblings" (como Riak)
# Merge: união de todos os valores com versão dominada removida
# A aplicação recebe todos os siblings e decide a semântica de merge
# Ex Dynamo: carrinho com items {A,B} e carrinho com items {A,C}
# Merge → siblings: [{A,B}, {A,C}]
# Aplicação: união = {A,B,C}

# TEXTO COLABORATIVO (RGA, LSEQ, Logoot):
# Google Docs, Figma, Notion — todos usam alguma variante
# O desafio: inserir caractere na posição 5 enquanto outro insere na posição 5
# RGA (Replicated Growable Array): cada caractere tem ID único e ponteiro para anterior
# LSEQ: cada posição tem identificador fracionário (1.3.7 fica entre 1.3 e 1.4)
# Merge: os IDs únicos resolvem o conflito determinísticamente
# Qualquer ordem de entrega das operações produz o mesmo documento final

# Quando NÃO usar CRDTs:
# - Operações que precisam de coordenação (transferência de dinheiro: A - 10, B + 10)
# - Conjuntos onde o tamanho importa (inventário: não pode vender o que não tem)
# - Leituras que precisam de snapshot consistente de múltiplos valores
# Para esses casos, volte a strong consistency ou use coordenação explícita.

Garantias de sessão: tornando eventual consistency utilizável

Terry et al. (1994) definiram quatro garantias de sessão que permitem ao developer raciocinar sobre o que ele vê, mesmo em sistemas eventualmente consistentes. São ortogonais ao modelo de consistência global — um sistema pode ser AP/eventual globalmente mas oferecer garantias fortes por sessão.

# As quatro garantias de sessão (Terry et al., 1994):

# 1. READ YOUR WRITES (RYW)
# Definição: após um write completar, reads subsequentes NESSA SESSÃO
#   sempre retornam o valor escrito ou algo mais recente.
# Problema resolvido: usuário cria post → recarrega página → post não aparece.
#   (Read foi para replica com lag; write estava no primary)
# Implementação A — sticky session: reads da mesma sessão sempre vão ao mesmo
#   nó que processou o write. Simples, mas cria hotspot e falha em failover.
# Implementação B — write token: write retorna um token (LSN/timestamp do write).
#   Reads subsequentes enviam o token; servidor só serve se replicou até esse LSN.
#   Se não replicou, serve do primary OU aguarda o lag.
# Implementação C — client-side clock: client rastreia o seu próprio "write_at"
#   timestamp. Reads especificam "quero valor mais recente que write_at".
# Quem oferece: DynamoDB (strongly consistent reads são RYW + MR),
#   Cassandra com SERIAL consistency em LWT, Cosmos DB com "Session" consistency.

# 2. MONOTONIC READS (MR)
# Definição: se você leu valor V da chave X, todas as leituras futuras
#   de X retornam V ou algo mais recente. Nunca "mais antigo".
# Problema resolvido: usuário vê 100 likes → recarrega → vê 95 likes.
#   (Round-robin entre replicas com lags diferentes)
# Implementação: track do LSN/timestamp da última leitura por chave.
#   Reads futuros especificam "mínimo este LSN". Replica que não atingiu
#   esse LSN não pode servir o request.
# Custo: o client (ou session layer) precisa manter state.

# 3. MONOTONIC WRITES (MW)
# Definição: writes de uma sessão são aplicados na ordem que foram feitos.
# Problema resolvido: banco de dados processa write B antes do write A
#   porque chegaram em nós diferentes e foram replicados out-of-order.
# Implementação: sequence number por sessão. Writes carregam o número de
#   sequência. Cada nó rejeita write fora de ordem (buffer até receber anterior).
# Quem precisa: sistemas de chat onde ordem das mensagens importa.

# 4. WRITES FOLLOW READS (WFR, Causal Writes)
# Definição: se você leu X=V e então escreveu Y, o write de Y é aplicado
#   em nós que já viram a versão V de X (ou mais recente).
# Problema resolvido: você lê "produto está disponível" (no nó A) e então
#   faz pedido (vai para nó B). Nó B ainda não viu que o produto estava disponível
#   → o write (pedido) chega a nó B antes do estado que o motivou.
# Implementação: reads retornam um "read token". Writes subsequentes levam
#   o token. O nó que processa o write verifica se conhece o estado referenciado.
# Mais complexo de implementar; raramente ofertado explicitamente.
# Causal consistency (nível de sistema) satisfaz WFR por design.

# COMBINAÇÕES COMUNS:
# RYW + MR: o par mais comum e mais útil. Evita o problema do "apareceu e sumiu".
# MW sozinho: sistemas de mensagens onde ordem interessa.
# Todos os quatro: causal consistency por sessão (Cosmos DB "Session" level).

# IMPLEMENTAÇÃO PRÁTICA EM CASSANDRA:
# Cassandra não oferece garantias de sessão nativas além do que o consistency
# level implica. Para RYW, o padrão é:
# - Escrever com QUORUM
# - Ler com QUORUM
# - QUORUM + QUORUM garante que reads veem writes recentes (W + R > N com N=3, W=2, R=2)
# Mas isso é mais caro que "eventual" (ONE). O tradeoff está sempre presente.

# DYNAMO / DYNAMODB:
# Consistency level por operação:
# - Eventually consistent reads: vão para qualquer replica, mais barato
# - Strongly consistent reads: vão para o leader, garantem RYW + MR
# - DynamoDB Transactions: serializable para escritas atômicas multi-item
# O desenvolvedor escolhe por operação — não é binário para o sistema inteiro.

Consistency models em sistemas reais

# CASSANDRA — tunable consistency por operação
# Consistency levels (CL):
#   ONE: resposta de 1 replica → fastest, sem garantias de freshness
#   TWO: resposta de 2 replicas
#   QUORUM: resposta de maioria (ceil(RF/2) + 1, onde RF = replication factor)
#   LOCAL_QUORUM: quorum dentro do DC local (multi-DC setup)
#   ALL: resposta de todas as replicas → mais forte, qualquer falha bloqueia
#   SERIAL/LOCAL_SERIAL: para Lightweight Transactions (compare-and-set)

# Com RF=3:
#   Write QUORUM + Read QUORUM: W=2, R=2, W+R=4 > 3 → sempre vê write recente
#   Write ONE + Read ONE: fastest, pode retornar stale data até segundos
#   Write ALL + Read ONE: durável, mas write falha se qualquer replica offline

# RIAK — conflict handling explícito
# Riak expõe "siblings": múltiplas versões concorrentes do mesmo objeto.
# A aplicação recebe todos os siblings e implementa merge customizado.
# Riak Data Types (RDTs): CRDTs built-in — counters, sets, maps, flags, registers.
# Com RDTs: merge é automático e sem siblings. Sem RDTs: app lida com conflitos.

# COUCHDB / POUCHDB — sync primeiro (offline-first)
# CouchDB foi projetado para sync em ambientes offline (ex: laptops desconectados).
# Revision IDs (_rev): cada documento tem árvore de revisões. Conflitos são
# "folhas" dessa árvore. A aplicação escolhe a "vencedora" e resolve o conflito.
# PouchDB (browser) sincroniza com CouchDB: o mesmo modelo funciona para apps
# mobile/web que precisam funcionar offline.

# SPANNER (Google) — consistência externa sem abrir mão de SQL
# TrueTime + serializable transactions: strong consistency com SQL completo.
# O "truque" do Spanner (discutido no C09) é usar GPS e relógios atômicos
# para dar timestamps com margem de erro conhecida — suficiente para
# serializabilidade externa sem necessitar consenso por transação.
# Custo: latência 10-20ms mesmo em operações locais (TrueTime commit wait).

# REDIS — linearizável no single-threaded principal
# Redis core: single-threaded. Comandos são executados atomicamente.
# Linearizável por definição dentro de uma única instância.
# Redis Cluster: eventual entre réplicas de um master (async replication).
# WAIT command: permite aguardar propagação para N replicas antes de confirmar.
# RedLock: lock distribuído usando múltiplos instâncias Redis — há debate
#   acadêmico se é seguro (Antirez vs Kleppmann, 2016); para uso crítico,
#   preferir Redisson + fencing token ou ZooKeeper + ephemeral nodes.

# MONGODB — evoluiu de eventual para configurável
# Historicamente: write concern default era não esperava durabilidade.
# Atual: write concern majority + read concern majority = strong consistency.
# linearizable read concern: garante linearizabilidade mas com custo alto.
# Change Streams: permite reagir a writes em real-time (base de invalidação de cache).

# POSTGRES — ACID + MVCC; não é distributed por padrão
# Dentro de uma instância: serializable isolamento disponível.
# Com streaming replication: reads de réplica têm lag (eventual).
# Synchronous_commit: wait para WAL chegar na réplica antes de ack → RYW garantido.
# Caveats do serializability: predicate locking; cuidado com long-running TX.

Arquitetura comparativa: modelos de consistência lado a lado

SISTEMA       CONSISTÊNCIA     MECANISMO           TRADEOFF
──────────────────────────────────────────────────────────────────────────
Postgres      Serializable     MVCC + predicate     Latência baixa (local)
(single)      (ACID)           locking              Não distribui por padrão

Spanner       Ext. Serlizble   TrueTime + Paxos     10-20ms min latency
              (CP)             por grupo            GPS hardware req.

CockroachDB   Serializable     Raft por range       2-5ms overhead vs Postgres
              (CP)             + 2PC cross-range    Distributed SQL

etcd          Linearizable     Raft + quorum        Throughput ~10k ops/s
              (CP)             log replication      Feito para config, não data

Cassandra     Tunable          Quorum votes         Tradeoff por operação
              (PA/EL default)  Leaderless           Sem transações multi-row

DynamoDB      Eventual         Leaderless +         Fortemente gerenciado
              (opt-in strong)  vector-clock         Custo RCU/WCU

Riak          Eventual +       Vector clocks        CRDT-native (RDTs)
              CRDT-native      Siblings para rest    Menos adotado hoje

Redis         Linearizable     Single-thread        In-memory; cluster eventual
              (instance)       Async replica        Não para source-of-truth

MongoDB       Configurável     MVCC + Raft          Flexível; defaults mudaram
              (up to lineariz) (desde 4.0)          muito no histórico

Kafka         Sequential       Partition leader     Ordering por partition
              (por partition)  + ISR replicas       Consumer group coordination
──────────────────────────────────────────────────────────────────────────

SESSION GUARANTEES: o que cada sistema oferece "out of the box"

Cassandra QUORUM:     RYW + MR implícito (se W+R > N)
DynamoDB strong:      RYW + MR (líder serve leitura)
DynamoDB eventual:    Nenhuma garantia de sessão
Cosmos DB Session:    RYW + MR + MW + WFR (tudo, por sessão)
Cosmos DB Bounded:    Leitura pode atrasar no máximo K versões ou T segundos
Cosmos DB Eventual:   Sem garantias
Postgres (read primary): RYW + MR + MW + WFR (single-writer)
Postgres (read replica): Eventual (lag existente)

NOTA: nenhuma das garantias acima é gratuita.
Cada uma troca latência, disponibilidade, ou custo de infraestrutura.
A escolha correta depende de qual anomalia o produto tolera.

Decisões de engenharia

Perguntas de entrevista

Exercícios práticos