PostgreSQL Multi-Região¶

Uma aplicação que roda em uma região e acessa um PostgreSQL em outra paga a latência do enlace em cada ida e volta. Como o PostgreSQL mantém um processo por conexão e o protocolo é conversacional, o efeito aparece duas vezes: no tempo de cada consulta e no custo de abrir conexões através da WAN.

O gargalo raramente é o banco. É a distância — e o desenho que a esconde.

A InteSys atua em todas as camadas desse problema, das otimizações transparentes para sistemas legados até arquiteturas regionais completas com replicação, cache e distribuição geográfica — operando nas duas regiões brasileiras Tier III: br-sp-1 (Cirion SAO1, Cotia/SP) e br-sp-2 (Equinix SP3, Tamboré/SP).

O problema¶

Entre br-sp-1 e br-sp-2 a latência é de poucos milissegundos — as duas regiões ficam na região metropolitana de São Paulo e se interligam por links Lan2Lan ou túneis criptografados. Já um enlace Brasil ↔ Estados Unidos opera em outra ordem de grandeza, acima de uma centena de milissegundos de RTT. É essa diferença que define quais consultas podem cruzar a WAN e quais precisam ser respondidas localmente.

Objetivos de uma arquitetura regional:

• reduzir a quantidade de consultas que cruzam a WAN;
• aproximar leituras e dados de alta frequência da aplicação;
• manter as escritas consistentes e controladas;
• eliminar o custo de abrir conexões através do enlace;
• preservar a compatibilidade com aplicações legadas;
• permitir evolução gradual, sem reescrita do sistema.

Catálogo de arquiteturas¶

1. Conectividade resiliente entre regiões¶

Antes de mexer no banco, estabilizamos o transporte: caminhos redundantes, VPNs, roteamento alternativo e observabilidade contínua de RTT, jitter e perda de pacotes.

Indicado para: ambientes com perda de pacotes ou dependência de um único caminho WAN. Limitação: não elimina a latência física entre as regiões.

2. Pooler de conexões próximo da aplicação¶

Um PgBouncer instalado na região da aplicação mantém conexões persistentes com o banco remoto e entrega conexões locais e baratas à aplicação. Em PostgreSQL isso vale ainda mais do que em outros bancos: cada conexão nova é um processo novo no servidor.

Indicado para: aplicações com muitas conexões curtas, serverless, PHP e workers. Benefícios: elimina o handshake pela WAN, protege o banco contra picos de conexão e cria um ponto único de observabilidade. Limitação: as consultas continuam indo à região remota.

3. Réplica de leitura no Brasil¶

O primário permanece onde está e um standby por streaming é mantido em br-sp-1 ou br-sp-2, atendendo as leituras locais em modo somente-leitura.

Indicado para: aplicações com volume relevante de leitura e tolerância a consistência eventual em parte das consultas. Benefícios: SELECT locais com baixa latência e redução expressiva do tempo médio de resposta. Ponto de atenção: leituras logo após uma escrita podem precisar ir ao primário.

4. Roteamento de leitura e escrita¶

A aplicação fala com um endpoint local. O pooler separa leitura de escrita; o cache atende os dados de alta frequência; a réplica atende as leituras selecionadas; o primário continua sendo a única autoridade de escrita.

O roteamento pode ser feito de duas formas, e ambas convivem bem:

• Na aplicação — dois data sources, um -rw e um -ro. É explícito, testável e evita surpresas de consistência.
• Na camada de proxy — o pooler expõe portas distintas para leitura e escrita, sem alteração no código.

Benefício: adoção progressiva, consulta a consulta, sem apostar tudo de uma vez.

5. Cache regional com Valkey/Redis¶

Dados repetitivos ficam em um Valkey ou Redis na região da aplicação: configurações, perfis, permissões, catálogos, sessões, resultados de consultas caras e dados derivados.

Indicado para: dados com alta taxa de leitura e estratégia de invalidação bem definida. Benefício: as consultas mais frequentes deixam de depender da distância até o banco.

6. Replicação física ou lógica¶

A replicação física copia o cluster inteiro e mantém o destino somente-leitura; a lógica replica o que foi escolhido e mantém o destino gravável.

A replicação lógica é também o caminho de menor risco para migrar um banco para a InteSys: sincroniza em produção e o cutover acontece em uma janela curta.

7. Camada regional de API / serviço de dados¶

Em sistemas novos ou em modernização, a aplicação deixa de executar dezenas de comandos SQL pela WAN e passa a chamar uma API regional, que executa a transação junto do banco.

Benefício: troca vários round trips SQL por uma única chamada de negócio.

8. Sharding geográfico / ownership regional¶

Os dados são particionados por cliente, tenant, país ou domínio funcional, e cada região grava o que é seu. Alta complexidade: exige regras claras de ownership, consistência e roteamento.

Alta disponibilidade entre br-sp-1 e br-sp-2¶

Reduzir latência resolve desempenho, não disponibilidade. Quando o banco é crítico, a InteSys distribui a solução entre as duas regiões brasileiras, independentes em energia, refrigeração e operadora, e separadas por poucos milissegundos.

Primário em uma região, standby síncrono na outra, pooler em alta disponibilidade nas duas e promoção controlada em caso de falha.

• Primário em br-sp-1, standby em br-sp-2 (ou o inverso) — a proximidade permite commit síncrono, com RPO zero, algo inviável em enlaces intercontinentais.
• Quórum síncrono (ANY 1 OF 2) para que a queda de um standby não bloqueie a escrita.
• Pooler em alta disponibilidade nas duas regiões, com VIP e o mesmo conjunto de regras, mantendo um endpoint único para a aplicação.
• Failover controlado — promoção com verificação de atraso e fencing do primário antigo, evitando split-brain.
• WAL arquivado e backup em armazenamento separado das duas regiões, com testes periódicos de restauração.
• Leituras aproveitam o standby: a região secundária atende consultas enquanto acompanha o primário.

Para o detalhamento da topologia, do failover e do backup, veja Alta Disponibilidade PostgreSQL.

PostgreSQL gerenciado em Kubernetes¶

Para clientes que já rodam suas aplicações em Kubernetes, operamos o PostgreSQL dentro do cluster, com um operador PostgreSQL cuidando do ciclo de vida do banco: topologia declarativa, failover automático, endpoints separados de leitura e escrita, anti-affinity entre nós e regiões, e arquivamento contínuo de WAL fora do cluster. Os detalhes estão em Alta Disponibilidade PostgreSQL.

Matriz de decisão¶

Por cenário¶

O que não deve ir para a réplica¶

Monitorar o atraso de replicação é parte da solução: as regras de roteamento devem reagir ao atraso e tirar a réplica de operação quando ela fica para trás.

Soberania de dados¶

Distribuir o banco entre regiões não significa tirar o dado do Brasil. As duas regiões da InteSys — br-sp-1 e br-sp-2 — são brasileiras, e uma topologia distribuída entre elas mantém residência de dados integral: primário, réplicas, arquivo de WAL e backup permanecem no país.

• Distribuição dentro do Brasil por padrão — a arquitetura descrita nesta página roda inteira em território nacional, sob a LGPD, sem transferência internacional a documentar.
• Réplica em outro país é decisão de conformidade, não só de latência — se a aplicação atende usuários fora do Brasil, a réplica de leitura naquela região significa dado pessoal saindo do país. Base legal, escopo e prazo de retenção entram no desenho, antes de configurar a replicação.
• Replicação lógica limita o escopo — dá para replicar apenas as tabelas que precisam estar na outra região e manter no Brasil o que é sensível. É a diferença prática entre a replicação física e a lógica descritas acima.
• Snapshot de volume criptografado — o cluster gerenciado em Kubernetes mantém snapshots em volume cifrado, com destino no Brasil (padrão) ou em outro país, quando o requisito é isolamento geográfico do backup. Detalhes em Alta Disponibilidade PostgreSQL.
• Jurisdição única quando esse é o requisito — infraestrutura, contrato e operação brasileiros, sem exposição a legislação estrangeira de acesso a dados.

Como a InteSys implanta¶

1. Diagnóstico — RTT, jitter, perda de pacotes, volume de conexões e comportamento transacional.
2. Observabilidade — identificação das consultas mais frequentes, mais lentas e mais sensíveis à WAN.
3. Pooler — PgBouncer na região da aplicação, com endpoints separados de leitura e escrita.
4. Regionalização da leitura — standby por streaming ou replicação lógica seletiva.
5. Cache — seleção dos dados adequados para Valkey/Redis e estratégia de invalidação.
6. Regras de consistência — leituras críticas no primário, consultas seguras na região local.
7. Alta disponibilidade — distribuição entre br-sp-1 e br-sp-2, com quórum síncrono e WAL arquivado fora das duas regiões.
8. Evolução arquitetural — API regional, Kubernetes ou banco distribuído, conforme a necessidade.

Próximos Passos¶

• Alta Disponibilidade PostgreSQL — Topologia, failover e backup dentro do datacenter
• CockroachDB Multi-Região — Escrita local em várias regiões, sem primário
• MySQL Multi-Região — As mesmas arquiteturas aplicadas ao MySQL
• Datacenters InteSys — Detalhes das regiões br-sp-1 e br-sp-2
• Visão Geral de DevOps — Catálogo completo de serviços