APRENDER. PRATICAR. EVOLUIR.Conceito e mecanismo
O modelo de dados deve representar invariantes do negócio e padrões de acesso. Antes de escolher armazenamento, identifica chaves, relações, transações, pesquisa, retenção e evolução. Uma réplica de leitura pode reduzir carga no primário mas não garante que uma escrita acabada de confirmar já esteja visível. No exemplo documentado de PostgreSQL18, streaming replication é assíncrona por omissão; o atraso pode traduzir-se em perda de escritas confirmadas se o primário falhar antes da réplica as receber. Modos síncronos têm condições específicas de espera e custo de disponibilidade. A decisão depende da operação e do risco aceite, não apenas da presença de uma segunda máquina.
Aplicação guiada
Num cenário fictício, uma aprovação lê um limite e atualiza uma reserva enquanto outra operação altera o mesmo estado. Define que invariantes precisam de sobreviver à concorrência. Em PostgreSQL18 Read Committed, duas consultas na mesma transação podem observar commits diferentes, porque o snapshot é por comando. Um nível mais forte pode exigir repetição de toda a transação quando há falha de serialização; repetir apenas a última escrita pode usar pressupostos antigos. Para uma confirmação apresentada ao utilizador, escolhe uma leitura com a frescura necessária ou comunica estado pendente. Documenta a garantia e a fronteira: isolamento local não cria uma transação automática entre todos os sistemas envolvidos.
Replicação, isolamento e backup respondem a problemas diferentes e precisam de critérios próprios.
Armadilhas comuns
Réplica como leitura sempre atual; commit local como conclusão global; retry parcial com decisões antigas.
Tópicos relacionados: Requisitos e decisões de arquitetura · Capacidade e latência · Cache, partições e filas
Escolhe consistência a partir do efeito que precisa de ser protegido.
Referência: PostgreSQL transaction isolation · System design patterns; PostgreSQL18 scoped examples; primary guidance consulted 2026-09-30