consistencia-leitura-replica

Consistência Leitura Réplica — Supabase + Supavisor + Realtime

Quando usar

LLM carrega esta skill ao usar Supabase Pro+ com read replicas ou ao combinar Realtime broadcast com leitura subsequente do DB. Trigger phrases:

• "Supabase read replica", "réplica de leitura"
• "porta 6543 vs 5432", "Supavisor session vs transaction"
• "read-after-write", "leitura após escrita inconsistente"
• "monotonic reads", "leituras não-monotônicas"
• "consistent prefix reads", "prefixo causal violado"
• "replication lag Supabase", "atraso de replicação"
• "broadcast Realtime + SELECT stale"
• "pg_last_wal_replay_lsn", "WAL position detection"

Esta skill aplica DDIA Ch 5 "Problems With Replication Lag" ao stack Supabase. Cross-referenciada por supabase-realtime (v1.8) ao bundlear broadcast + leitura, e por multi-tenant-performance-scaling (v1.21) ao escalar Postgres em Pro+.

Termos canônicos (read-after-write consistency, monotonic reads, consistent prefix reads, replication lag, leader-follower replication) definidos em _shared-dados-distribuidos/glossary.md seções (a) e (b) — esta skill não duplica, apenas linka.

Regras absolutas

REGRA #1 (read-after-write own data): Para leituras do próprio dado do usuário dentro de janela de 5s após write, rotear para porta 5432 (líder) — não 6543. Sem isso, usuário cria post → GET retorna 404 → percepção de bug. Justify: DDIA p. 156 "always read the user's own profile from the leader".

REGRA #2 (sticky session monotonic): Para usuários ativos lendo de réplicas, escolher réplica via hash(user_id) mod N — não round-robin. Round-robin viola monotonic reads (DDIA p. 158). Mitigação obrigatória: fallback para líder se réplica down.

REGRA #3 (broadcast trust payload): Após receber Realtime broadcast com payload.record, NÃO fazer SELECT subsequente. Confiar no payload — server é a fonte canônica do evento. SELECT pode atingir réplica que ainda não replicou (lag típico 50-500ms).