PostgreSQL Multi-Región¶

Una aplicación que corre en una región y accede a un PostgreSQL en otra paga la latencia del enlace en cada ida y vuelta. Como PostgreSQL mantiene un proceso por conexión y el protocolo es conversacional, el efecto aparece dos veces: en el tiempo de cada consulta y en el coste de abrir conexiones a través de la WAN.

El cuello de botella rara vez es la base de datos. Es la distancia — y el diseño que la oculta.

InteSys actúa en todas las capas de ese problema, desde optimizaciones transparentes para sistemas legados hasta arquitecturas regionales completas con replicación, caché y distribución geográfica — operando en las dos regiones brasileñas Tier III: br-sp-1 (Cirion SAO1, Cotia/SP) y br-sp-2 (Equinix SP3, Tamboré/SP).

El problema¶

Entre br-sp-1 y br-sp-2 la latencia es de pocos milisegundos — ambas regiones están en el área metropolitana de São Paulo y se interconectan mediante enlaces Lan2Lan o túneles cifrados. Un enlace Brasil ↔ Estados Unidos opera en otro orden de magnitud, por encima de un centenar de milisegundos de RTT. Esa diferencia define qué consultas pueden cruzar la WAN y cuáles deben responderse localmente.

Objetivos de una arquitectura regional:

• reducir la cantidad de consultas que cruzan la WAN;
• acercar lecturas y datos de alta frecuencia a la aplicación;
• mantener las escrituras consistentes y controladas;
• eliminar el coste de abrir conexiones a través del enlace;
• preservar la compatibilidad con aplicaciones legadas;
• permitir una evolución gradual, sin reescribir el sistema.

Catálogo de arquitecturas¶

1. Conectividad resiliente entre regiones¶

Antes de tocar la base de datos, estabilizamos el transporte: caminos redundantes, VPNs, enrutamiento alternativo y observabilidad continua de RTT, jitter y pérdida de paquetes.

Recomendado para: entornos con pérdida de paquetes o dependencia de un único camino WAN. Limitación: no elimina la latencia física entre las regiones.

2. Pooler de conexiones cerca de la aplicación¶

Un PgBouncer instalado en la región de la aplicación mantiene conexiones persistentes con la base remota y entrega conexiones locales y baratas a la aplicación. En PostgreSQL esto vale aún más que en otras bases: cada conexión nueva es un proceso nuevo en el servidor.

Recomendado para: aplicaciones con muchas conexiones cortas, serverless, PHP y workers. Beneficios: elimina el handshake por la WAN, protege la base contra picos de conexión y crea un punto único de observabilidad. Limitación: las consultas siguen yendo a la región remota.

3. Réplica de lectura en Brasil¶

El primario permanece donde está y se mantiene un standby por streaming en br-sp-1 o br-sp-2, atendiendo las lecturas locales en modo solo lectura.

Recomendado para: aplicaciones con volumen relevante de lectura y tolerancia a consistencia eventual en parte de las consultas. Beneficios: SELECT locales con baja latencia y reducción notable del tiempo medio de respuesta. Punto de atención: las lecturas inmediatamente posteriores a una escritura pueden necesitar ir al primario.

4. Enrutamiento de lectura y escritura¶

La aplicación habla con un endpoint local. El pooler separa lectura de escritura; la caché atiende los datos de alta frecuencia; la réplica atiende las lecturas seleccionadas; el primario sigue siendo la única autoridad de escritura.

El enrutamiento puede hacerse de dos formas, y ambas conviven bien:

• En la aplicación — dos data sources, uno -rw y otro -ro. Es explícito, comprobable y evita sorpresas de consistencia.
• En la capa de proxy — el pooler expone puertos distintos para lectura y escritura, sin cambios en el código.

Beneficio: adopción progresiva, consulta a consulta, sin apostarlo todo de una vez.

5. Caché regional con Valkey/Redis¶

Los datos repetitivos quedan en un Valkey o Redis en la región de la aplicación: configuraciones, perfiles, permisos, catálogos, sesiones, resultados de consultas costosas y datos derivados.

Recomendado para: datos con alta tasa de lectura y estrategia de invalidación bien definida. Beneficio: las consultas más frecuentes dejan de depender de la distancia hasta la base de datos.

6. Replicación física o lógica¶

La replicación física copia el clúster entero y mantiene el destino en solo lectura; la lógica replica lo que se eligió y mantiene el destino escribible.

La replicación lógica es además el camino de menor riesgo para migrar una base de datos a InteSys: sincroniza en producción y el cutover ocurre en una ventana corta.

7. Capa regional de API / servicio de datos¶

En sistemas nuevos o en modernización, la aplicación deja de ejecutar decenas de comandos SQL por la WAN y pasa a llamar a una API regional, que ejecuta la transacción junto a la base de datos.

Beneficio: cambia varios round trips SQL por una única llamada de negocio.

8. Sharding geográfico / ownership regional¶

Los datos se particionan por cliente, tenant, país o dominio funcional, y cada región graba lo suyo. Alta complejidad: exige reglas claras de ownership, consistencia y enrutamiento.

Alta disponibilidad entre br-sp-1 y br-sp-2¶

Reducir la latencia resuelve el rendimiento, no la disponibilidad. Cuando la base de datos es crítica, InteSys distribuye la solución entre las dos regiones brasileñas, independientes en energía, refrigeración y operadora, y separadas por pocos milisegundos.

Primario en una región, standby síncrono en la otra, pooler en alta disponibilidad en ambas y promoción controlada en caso de fallo.

• Primario en br-sp-1, standby en br-sp-2 (o al revés) — la proximidad permite commit síncrono, con RPO cero, algo inviable en enlaces intercontinentales.
• Quórum síncrono (ANY 1 OF 2) para que la caída de un standby no bloquee la escritura.
• Pooler en alta disponibilidad en ambas regiones, con VIP y el mismo conjunto de reglas, manteniendo un endpoint único para la aplicación.
• Failover controlado — promoción con verificación de retraso y fencing del primario antiguo, evitando el split-brain.
• WAL archivado y backup en almacenamiento separado de ambas regiones, con pruebas periódicas de restauración.
• Las lecturas aprovechan el standby: la región secundaria atiende consultas mientras sigue al primario.

Para el detalle de la topología, el failover y el backup, consulte Alta Disponibilidad PostgreSQL.

PostgreSQL gestionado en Kubernetes¶

Para clientes que ya ejecutan sus aplicaciones en Kubernetes, operamos PostgreSQL dentro del clúster, con un operador PostgreSQL a cargo del ciclo de vida de la base: topología declarativa, failover automático, endpoints separados de lectura y escritura, anti-affinity entre nodos y regiones, y archivado continuo de WAL fuera del clúster. Los detalles están en Alta Disponibilidad PostgreSQL.

Matriz de decisión¶

Por escenario¶

Qué no debe ir a la réplica¶

Monitorizar el retraso de replicación es parte de la solución: las reglas de enrutamiento deben reaccionar al retraso y sacar la réplica de operación cuando se queda atrás.

Soberanía de datos¶

Distribuir la base entre regiones no significa sacar el dato de Brasil. Las dos regiones de InteSys — br-sp-1 y br-sp-2 — son brasileñas, y una topología distribuida entre ambas mantiene residencia de datos íntegra: primario, réplicas, archivo de WAL y backup permanecen en el país.

• Distribución dentro de Brasil por defecto — la arquitectura descrita en esta página se ejecuta entera en territorio brasileño, bajo la LGPD, sin transferencia internacional que documentar.
• Una réplica en otro país es una decisión de cumplimiento, no solo de latencia — si la aplicación atiende usuarios fuera de Brasil, la réplica de lectura en esa región significa dato personal saliendo del país. Base legal, alcance y retención se definen en el diseño, antes de configurar la replicación.
• La replicación lógica limita el alcance — se pueden replicar solo las tablas que necesitan estar en la otra región y mantener en Brasil lo sensible. Es la diferencia práctica entre la replicación física y la lógica descritas arriba.
• Snapshot de volumen cifrado — el clúster gestionado en Kubernetes mantiene snapshots en volumen cifrado, con destino en Brasil (por defecto) o en otro país, cuando el requisito es aislamiento geográfico del backup. Detalles en Alta Disponibilidad PostgreSQL.
• Jurisdicción única cuando ese es el requisito — infraestructura, contrato y operación brasileños, sin exposición a legislación extranjera de acceso a datos.

Cómo lo implementa InteSys¶

1. Diagnóstico — RTT, jitter, pérdida de paquetes, volumen de conexiones y comportamiento transaccional.
2. Observabilidad — identificación de las consultas más frecuentes, más lentas y más sensibles a la WAN.
3. Pooler — PgBouncer en la región de la aplicación, con endpoints separados de lectura y escritura.
4. Regionalización de la lectura — standby por streaming o replicación lógica selectiva.
5. Caché — selección de los datos adecuados para Valkey/Redis y estrategia de invalidación.
6. Reglas de consistencia — lecturas críticas en el primario, consultas seguras en la región local.
7. Alta disponibilidad — distribución entre br-sp-1 y br-sp-2, con quórum síncrono y WAL archivado fuera de ambas regiones.
8. Evolución arquitectónica — API regional, Kubernetes o base distribuida, según la necesidad.

Próximos Pasos¶

• Alta Disponibilidad PostgreSQL — Topología, failover y backup dentro del centro de datos
• CockroachDB Multi-Región — Escritura local en varias regiones, sin primario
• MySQL Multi-Región — Las mismas arquitecturas aplicadas a MySQL
• Centros de Datos InteSys — Detalles de las regiones br-sp-1 y br-sp-2
• Visión General de DevOps — Catálogo completo de servicios