Read Replicas PostgreSQL no Node.js distribuem consultas de leitura para servidores secundários, reduzindo carga no primário. A estratégia melhora capacidade de leitura, mas introduz replicação assíncrona e possibilidade de dados temporariamente atrasados.
Primário e réplica
Escritas continuam no primário. Consultas tolerantes a atraso podem usar réplicas. A aplicação precisa escolher explicitamente o destino.
import pg from 'pg';
const writer = new pg.Pool({ connectionString: process.env.WRITER_URL });
const reader = new pg.Pool({ connectionString: process.env.READER_URL });Repository com leitura separada
export function createOrdersRepository({ writer, reader }) {
return {
async create(input) {
return writer.query('INSERT INTO orders ...', []);
},
async listRecent() {
return reader.query('SELECT * FROM orders ORDER BY created_at DESC LIMIT 50');
}
};
}Read-after-write
Após criar um registro, uma leitura imediata na réplica pode não encontrá-lo. Para fluxos que exigem consistência, leia do primário por um período ou retorne o resultado da própria escrita.
Replication lag
Meça atraso em bytes e tempo. Quando a réplica está muito atrasada, retire-a temporariamente do tráfego ou direcione consultas críticas ao primário.
Escolha de consultas
Boas candidatas:
- relatórios;
- listas e dashboards;
- buscas;
- exportações;
- consultas analíticas moderadas.
Operações de autorização, saldo, estoque e confirmação após escrita podem exigir o primário.
Transações
Não divida uma transação entre writer e reader. Todas as queries da transação devem usar a mesma conexão do primário.
Consulte Transações PostgreSQL no Node.js.
Balanceamento entre réplicas
Com várias réplicas, escolha por round-robin, peso, região ou latência. Remova instâncias com erro e limite retries pelo deadline.
Pool de conexões
Mantenha limites separados para primário e réplicas. A soma de todas as instâncias da aplicação não pode exceder a capacidade do banco. Veja Connection Pooling no Node.js.
Falha da réplica
Defina comportamento explícito: fallback para primário, resposta degradada ou indisponibilidade da funcionalidade. Evite fallback ilimitado que sobrecarregue o writer.
Cache
Read replicas não substituem cache. Elas reduzem carga de leitura no primário, mas ainda executam queries e podem sofrer com consultas ineficientes.
Observabilidade
Monitore:
- lag por réplica;
- latência e erros;
- conexões ativas;
- queries por destino;
- fallbacks ao primário;
- conflitos de recuperação;
- uso de CPU e I/O.
Erros comuns
- enviar toda leitura à réplica;
- ignorar read-after-write;
- não medir lag;
- fallback sem limite;
- usar réplica dentro de transação de escrita;
- criar pools demais;
- acreditar que réplica corrige query ruim.
Conclusão
Read Replicas PostgreSQL no Node.js ampliam capacidade de leitura quando a aplicação aceita consistência eventual. Classifique consultas, meça lag e preserve o primário para operações críticas.
Consulte a documentação de warm standby do PostgreSQL e a documentação de pools do node-postgres.
