Read replication global

Toda base de datos en un solo lugar es rápida para quien está cerca y lenta para quien está lejos, y en una red global casi todos están lejos. La replicación de lectura de D1 ataca el problema de raíz: coloca copias de solo lectura de tu base en regiones repartidas por el mundo, de modo que la lectura de un usuario en Sídney no tenga que cruzar el planeta hasta la primaria en Fráncfort. El precio de esa cercanía es una verdad incómoda: esas copias van, por diseño, un instante atrasadas.

Una primaria, muchas réplicas

Sin replicación, D1 enruta cada consulta —lea o escriba— a una única instancia en una sola región del mundo, la primaria. La latencia de cada petición depende de la distancia física a ese punto: un usuario al otro lado del planeta paga el round-trip completo en cada consulta, y ninguna optimización de tu código lo evita, porque el coste es la velocidad de la luz recorriendo la fibra.

Con replicación, Cloudflare crea copias asíncronas de solo lectura, las réplicas, en varias regiones de su red. El usuario lejano de la primaria puede estar, en cambio, cerca de una réplica; cuando su lectura se atiende ahí, la respuesta llega en una fracción del tiempo. Las réplicas se crean de forma automática, se activan o duermen según el tráfico, y el enrutamiento es transparente: tú no eliges la réplica, la red te acerca a la más próxima.

Que el enrutamiento sea transparente tiene una consecuencia liberadora: no escribes lógica de geolocalización, no eliges centros de datos, no mantienes una tabla de qué usuario va a qué réplica. Declaras, mediante la sesión, cuánta frescura necesita cada consulta, y la plataforma resuelve el dónde. Es infraestructura que desaparece, que es la mejor clase de infraestructura.

Y que las réplicas se activen y duerman según el tráfico significa que no pagas por capacidad ociosa ni gestionas un parque de servidores: una base con lectores en Asia despierta la réplica de Asia; una sin tráfico allí no la mantiene encendida. La topología sigue a la demanda, sola.

Replicación asíncrona y replica lag

La palabra que lo explica todo es asíncrona. La primaria confirma una escritura sin esperar a que las réplicas la reciban, y propaga el cambio después. El intervalo entre que la primaria confirma un dato y una réplica lo tiene se llama replica lag, y durante esa ventana la réplica sirve, con total normalidad, una versión anterior de la base.

Esto no es un defecto a corregir, es el mecanismo mismo que compra la velocidad. Si cada escritura tuviera que esperar la confirmación de todas las réplicas del planeta, la latencia de escritura sería intercontinental y habríamos perdido justo lo que vinimos a ganar. El replica lag es el coste estructural de tener copias cercanas; la pregunta de ingeniería no es cómo eliminarlo, sino cómo tolerarlo sin servir datos que contradigan lo que el usuario ya vio.

El tamaño típico de ese atraso es pequeño —la propagación es continua, no por lotes espaciados—, pero su valor exacto es, por naturaleza, no garantizado: puede crecer bajo carga o si una región queda momentáneamente rezagada. Diseñar suponiendo un número concreto de milisegundos sería frágil; lo robusto es diseñar suponiendo solo que el atraso existe y puede variar, y dejar que el bookmark imponga la frescura cuando importa.

Conviene situar esto en el mapa de garantías: la primaria ofrece siempre la última verdad porque toda escritura pasa por ella; las réplicas ofrecen frescura acotada. No hay una tercera opción mágica de rápido y siempre lo último desde cualquier parte, porque esa opción contradice la física de una red planetaria. Elegir es, aquí, inevitable, y la Sessions API es lo que vuelve esa elección barata y explícita.

flowchart TD
P[primaria unica escrituras] -->|replicacion asincrona| R1[replica wnam]
P -->|replicacion asincrona| R2[replica weur]
P -->|replicacion asincrona| R3[replica apac]
U1[usuario en europa] -->|lectura cercana| R2
U2[usuario en asia] -->|lectura cercana| R3
style P fill:#f38ba8,color:#11111b
style R1 fill:#a6e3a1,color:#11111b
style R2 fill:#a6e3a1,color:#11111b
style R3 fill:#a6e3a1,color:#11111b

Activar y observar

La replicación se activa por base, no por consulta. Desde el panel de D1, en los ajustes de tu base, la habilitas; o por la REST API poniendo el modo en automático:

curl -X PUT "https://api.cloudflare.com/client/v4/accounts/$ID/d1/database/$DB" \
  -H "Authorization: Bearer $TOKEN" \
  -d '{"read_replication": {"mode": "auto"}}'

Pero activarla no basta: si sigues consultando env.DB directamente, todo va a la primaria como antes. Las réplicas solo entran en juego cuando usas la Sessions API. Para ver qué ocurre, cada resultado trae en su objeto meta los campos served_by_region y served_by_primary, que te dicen dónde se atendió la consulta.

const r = await env.DB.withSession().prepare("SELECT 1").run();
console.log(r.meta.served_by_region, r.meta.served_by_primary);

Estos campos son tu ventana a la topología: si una lectura que esperabas cercana sigue marcando served_by_primary, sabrás que algo —un bookmark demasiado exigente, una escritura previa en la sesión— la está forzando a la primaria. Observar antes de optimizar es la regla, y aquí la observación viene incluida en cada respuesta.

Comprobar si la replicación está activa es igual de directo por la REST API: pides la base y miras el modo.

curl -X GET "https://api.cloudflare.com/client/v4/accounts/$ID/d1/database/$DB" \
  -H "Authorization: Bearer $TOKEN"
# el campo read_replication.mode sera auto o disabled

Con el modo en auto, D1 mantiene una réplica en cada región soportada y la despierta según el tráfico; tú no gestionas ninguna instancia. Administras solo la decisión de consistencia por consulta, que ya vive en tu código a través de la sesión. Esa división del trabajo —Cloudflare opera la topología, tú declaras la frescura— es lo que hace que la replicación se sienta gratis de operar.

El compromiso de consistencia

Lo que ganas es nítido: menor latencia de lectura para usuarios lejanos y más rendimiento agregado, porque muchas instancias reparten la carga de lectura. Lo que arriesgas es la frescura: sin cuidado, una lectura puede caer en una réplica atrasada y contradecir una escritura reciente.

El modelo que D1 ofrece para gobernar ese riesgo es la consistencia secuencial, y se obtiene con la Sessions API de la lección anterior. No es la consistencia más fuerte posible —no es serializabilidad estricta ni linealizabilidad global—, pero sí la más fuerte que un sistema global puede dar sin sacrificar la latencia: dentro de una sesión, las lecturas son monótonas, las escrituras son monótonas, y siempre lees tus propias escrituras.

La decisión de diseño, entonces, no es si replicar o no, sino qué consultas toleran un dato de hace un segundo y cuáles exigen la última verdad. Esa clasificación —hecha endpoint a endpoint, no de una vez para toda la base— es el verdadero trabajo de ingeniería que la replicación te pide a cambio de su velocidad.

Un modo útil de internalizarlo: la replicación no cambia qué datos tiene tu base, cambia dónde y cuándo puede leerlos cada usuario. Es una decisión sobre el espacio y el tiempo del acceso, no sobre el contenido. Por eso se activa sin migrar nada y se razona consulta a consulta, no tabla a tabla.

Un patrón mental ayuda a decidir rápido: separa tus rutas en las que leen para mostrar y las que leen para decidir. Un listado de artículos, un perfil público o un panel de métricas leen para mostrar, y toleran de sobra un dato de hace un instante; una comprobación de saldo antes de cobrar o una validación de stock antes de vender leen para decidir, y ahí exiges la primaria o esperas al bookmark. Y como la observación viene incluida, la clasificación no es teórica: despliega, mira served_by_region en tus rutas reales y deja que los datos confirmen si acertaste al etiquetar cada consulta.