¿Qué es la replicación de base de datos multi-región?

La replicación multi-región es una topología de base de datos que copia datos entre regiones geográficas para reducir latencia de lectura y sobrevivir caídas. El enemigo es la física: una ida y vuelta cruzando un océano cuesta decenas de milisegundos antes de que la base haga trabajo alguno, y los patrones de solicitud parlanchines lo pagan repetidamente. La replicación lleva los datos hasta los usuarios — e inmediatamente plantea las preguntas que definen este tema: quién acepta escrituras, qué tan desactualizadas pueden estar las lecturas, y si ya necesitas algo de esto.

Puntos clave

Mide antes de replicar

Antes de cualquier decisión de topología, consigue el número del que depende — cuánto le cuesta de verdad una ida y vuelta a tus usuarios, por región:

// JavaScript / Node.js — Back4app JS SDK
// Latency probe: measure what users in this region actually feel
const probe = new Parse.Query('HealthCheck');
probe.limit(1);

const started = Date.now();
await probe.first();               // one lightweight read
const readMs = Date.now() - started;

const sample = new Parse.Object('LatencySample');
sample.set('clientRegion', 'eu');  // where this client runs
sample.set('readMs', readMs);
await sample.save();               // writes always travel to the primary

console.log(`read: ${readMs} ms — reads can be served locally,`);
console.log('writes pay the distance to the primary region');

// Flutter / Dart — Back4app Flutter SDK
// Latency probe: measure what users in this region actually feel
final probe = QueryBuilder<ParseObject>(ParseObject('HealthCheck'))
  ..setLimit(1);

final started = DateTime.now();
await probe.query();               // one lightweight read
final readMs = DateTime.now().difference(started).inMilliseconds;

final sample = ParseObject('LatencySample')
  ..set('clientRegion', 'eu')      // where this client runs
  ..set('readMs', readMs);
await sample.save();               // writes always travel to the primary

print('read: $readMs ms — reads can be served locally,');
print('writes pay the distance to the primary region');

// iOS / Swift — Back4app Swift SDK
// Latency probe: measure what users in this region actually feel
let probe = HealthCheck.query().limit(1)

let started = Date()
probe.first { result in            // one lightweight read
  let readMs = Int(Date().timeIntervalSince(started) * 1000)

  var sample = LatencySample()
  sample.clientRegion = "eu"       // where this client runs
  sample.readMs = readMs
  sample.save { _ in               // writes always travel to the primary
    print("read: \(readMs) ms — reads can be served locally,")
    print("writes pay the distance to the primary region")
  }
}

// Android / Kotlin — Back4app Android SDK
// Latency probe: measure what users in this region actually feel
val probe = ParseQuery.getQuery<ParseObject>("HealthCheck")
probe.limit = 1

val started = System.currentTimeMillis()
probe.getFirstInBackground { _, e ->      // one lightweight read
    val readMs = System.currentTimeMillis() - started

    val sample = ParseObject("LatencySample")
    sample.put("clientRegion", "eu")      // where this client runs
    sample.put("readMs", readMs)
    sample.saveInBackground {             // writes travel to the primary
        println("read: $readMs ms — reads can be served locally,")
        println("writes pay the distance to the primary region")
    }
}

Cuando los números sí justifican réplicas, la maquinaria es estándar — aquí como replicación lógica de PostgreSQL, con el lag como hecho consultable de primera clase:

-- En el primario (región A): publica los cambios
CREATE PUBLICATION app_pub FOR ALL TABLES;

-- En la réplica (región B): suscríbete y recibe el stream
CREATE SUBSCRIPTION app_sub
  CONNECTION 'host=primary.internal dbname=app'
  PUBLICATION app_pub;

-- El número que define tu ventana de desactualización:
SELECT application_name,
       now() - reply_time AS approx_lag
FROM pg_stat_replication;

Un primario, muchas regiones — el flujo y el lag

Esta es la topología caballo de batalla — replica sets en bases de documentos, réplicas en streaming en las relacionales — y sus dos costos están visibles en el diagrama. Latencia de escritura: toda escritura viaja a la región del primario, así que los usuarios distantes pagan el cruce del océano precisamente en sus acciones que mutan datos. Lag: los streams entre regiones son asíncronos — la replicación síncrona sumaría la ida y vuelta completa a cada commit —, así que las réplicas van atrasadas de milisegundos a segundos, y las lecturas pueden estar desactualizadas en esa medida. La mordida clásica es el read-your-own-writes: guardar, refrescar contra la réplica local, no ver nada. Los remedios son política de enrutamiento, no magia — envía las lecturas post-escritura del usuario al primario, o fija su sesión hasta que la réplica se ponga al día.

El paso siguiente — múltiples primarios de escritura — localiza también las escrituras, pero compra la mercancía más difícil del teorema CAP: las escrituras concurrentes y conflictivas en regiones distintas deben detectarse y resolverse. Las cargas libres de conflicto (datos por usuario, streams append-only) lo llevan bien; el estado mutable compartido lo lleva mal.

Región única vs. réplicas de lectura vs. multi-primario

La lectura honesta de la tabla: cada columna hacia la derecha cambia simplicidad por localidad. La mayoría de los productos debería pararse en la columna más a la izquierda que cumpla sus números de latencia y disponibilidad — y muchos descubren que un CDN para los assets más una región de base de datos bien elegida ya los cumple, porque el peso estático suele dominar el tiempo de carga percibido.

Casos de uso comunes

• Productos globales de lectura intensa. Catálogos, contenido, dashboards — tráfico dominado por la navegación, donde las réplicas regionales convierten océanos en milisegundos de un dígito.
• Bases de usuarios regionales con cola global. Primario en la región del mercado principal, réplicas donde vive la cola.
• Disaster recovery y failover. Una copia al día en otra región como historia de disponibilidad — valiosa incluso cuando la latencia nunca justificó réplicas.
• Residencia de datos. Mantener los datos de ciertos tenants en jurisdicciones específicas — particionamiento consciente del tenant por región, un primo de política de la replicación.
• Seguro de portabilidad. Replicar sobre motores open-source mantiene la topología tuya — una cobertura silenciosa contra el vendor lock-in que las bases globales propietarias no ofrecen.

¿Deberías ir multi-región? Matriz de decisión

El orden del diagnóstico importa: perfila las consultas y agrega índices primero, agrupa los patrones de solicitud parlanchines segundo, pon los assets estáticos en un CDN tercero, ubica bien tu región única cuarto — y replica quinto, cuando la latencia restante sea genuinamente geográfica. Los equipos que saltan directo al quinto heredan problemas de sistemas distribuidos mientras su cuello de botella real era una consulta sin índice.

Limitaciones y trade-offs

• El lag es estructural. Los streams asíncronos van atrasados por diseño; toda lectura en réplica carga una ventana de desactualización que tu producto debe tolerar o esquivar por enrutamiento.
• Las escrituras siguen cruzando el océano. Las topologías de primario único localizan solo las lecturas — el checkout, el post, la reserva siguen pagando la distancia.
• El failover es un procedimiento, no una promesa. Promoción, cutover y el riesgo de perder escrituras no replicadas (RPO otra vez) — ensáyalo antes de creerlo.
• Multi-primario importa conflictos. Las escrituras concurrentes al mismo registro en dos regiones deben fusionarse de algún modo; “gana la última escritura” es una política de pérdida de datos vestida de valor por defecto.
• El costo escala con las copias. Almacenamiento, tráfico de salida entre regiones y la atención de ingeniería de un sistema distribuido más — cotizados con honestidad, por región.
• La replicación no es backup. Toda réplica copia fielmente tus errores en segundos; el point-in-time recovery existe para la clase de falla que la replicación propaga.

Multi-región y latencia en Back4app

Back4app es una plataforma open-source de Backend as a Service (BaaS) que combina base de datos gestionada, APIs REST y GraphQL generadas automáticamente, autenticación, almacenamiento de archivos y funciones serverless con Cloud Code. La mecánica de replicación vive debajo de tu código: la base de datos gestionada corre sobre infraestructura replicada con failover manejado por la plataforma, y la elección de región al crear la app pone el primario donde están tus usuarios — la decisión de latencia de mayor apalancamiento que este artículo recomienda tomar primero. Como el stack es open source de punta a punta, la topología sigue siendo portable: el mismo Parse Server y los mismos motores de base de datos corren donde sea que más adelante necesites una región que el menú de la plataforma no liste.