Edge frente a región

La forma clásica de desplegar un backend empieza por una pregunta: en qué región. Eliges un centro de datos, colocas ahí tu servidor y tu base de datos, y el mundo entero paga la distancia hasta ese punto. El edge borra esa primera pregunta y, con ella, una lista entera de supuestos que dábamos por eternos. Esta lección los pone cara a cara —supuesto por supuesto— para que veas exactamente qué cambia al pasar de una región al borde, y qué problema nuevo aparece en el camino.

El modelo regional

Durante dos décadas, la nube significó alquilar máquinas en una región. Levantas una VM o defines una función serverless, eliges us-east-1 o eu-west-1, y ahí vive tu aplicación. Cerca despliegas la base de datos, y el conjunto funciona como una unidad en un punto concreto del mapa.

Ese modelo no es malo —ha sostenido internet durante años— pero trae consigo una serie de supuestos que casi nunca cuestionamos porque venían de fábrica:

El supuesto más silencioso, y el que más nos costará soltar, es que el compute y los datos están juntos. En una región, el servidor y la base de datos comparten centro de datos: hablar con la base de datos es casi gratis, cuestión de menos de un milisegundo. Todo el diseño tradicional se apoya, sin decirlo, en esa cercanía.

En código, ese supuesto se ve en cada backend regional: una cadena de conexión que apunta a un host concreto y un pool que se mantiene abierto.

// El patron regional: un host fijo y un pool persistente,
// que solo tiene sentido si el compute vive junto a la base de datos.
const pool = new Pool({
  host: "db.us-east-1.internal",
  max: 20,
  idleTimeoutMillis: 30000,
});

El modelo edge

En el edge, la unidad de despliegue no es una máquina en una región: es una función que existe en toda la red a la vez. No hay región que elegir, no hay contenedor que arrancar, no hay servidor que mantener encendido.

Ese cambio de unidad reordena el ciclo de vida entero:

• Nace por petición: el isolate se activa cuando llega una request y puede descartarse después.
• Vive en todas partes: no en una zona, sino en cada PoP que reciba tráfico.
• No guarda estado en memoria entre peticiones: el estado va a un binding, no a una variable global.
• No se administra: ni tamaño de instancia, ni parches, ni escalado manual.

flowchart TB
subgraph Modelo_regional
  A[Usuario lejano] --> B[Viaje largo hasta la region]
  B --> C[Un servidor y una base de datos]
end
subgraph Modelo_edge
  D[Usuario] --> E[PoP mas cercano]
  E --> F[Tu Worker ya esta aqui]
end
style C fill:#f38ba8,color:#11111b
style F fill:#a6e3a1,color:#11111b

Puesto frente a los cuatro supuestos anteriores, el contraste es limpio:

• No hay una región: el Worker corre en el PoP de cada usuario. La cercanía es el estado por defecto, no una configuración.
• No hay cold starts: un isolate de V8 arranca en cero milisegundos sobre un proceso ya caliente; no hay contenedor que levantar.
• No hay conexión persistente al uso: un Worker es efímero y global, así que no puede sostener un pool clásico; el acceso a datos se repiensa con bindings, KV, D1 o Hyperdrive.
• Escalar es gratis y geográfico: ya estás en todas partes desde el primer despliegue; no replicas a mano.

// No hay region ni pool persistente que configurar.
// El Worker recibe sus recursos por 'env', ya conectados y globales.
export default {
  async fetch(request, env) {
    const valor = await env.MI_KV.get("clave");
    return new Response(valor ?? "sin datos");
  },
};

Fíjate en que no aparece ninguna cadena de conexión, ninguna región, ningún host: solo env.MI_KV, un binding declarado en la configuración. El recurso llega ya resuelto y disponible en cada PoP. Esa ausencia de fontanería no es azar: es la forma que toma el edge cuando ninguna de las suposiciones regionales sigue en pie.

Qué supuesto nace en el edge

Cambiar de modelo no elimina los problemas: los mueve. Recordemos el supuesto silencioso de la región —compute y datos juntos—. El edge lo rompe de raíz. Si tu Worker corre en cientos de ciudades pero tu base de datos sigue en una sola región, cada consulta vuelve a cruzar el planeta. Has acercado el compute al usuario y, sin querer, has alejado el compute de los datos.

Por eso el catálogo de almacenamiento de Cloudflare no es una lista de productos redundantes, sino un conjunto de respuestas distintas a la misma pregunta nueva:

No hay que elegir uno para siempre: una misma app puede usar KV para configuración global, D1 para sus tablas y Durable Objects para sesiones en vivo. La pregunta deja de ser cuál es el mejor almacén y pasa a ser cuál acerca estos datos a estos accesos.

El cambio de mentalidad

Resumido en una tabla, el salto mental es este: