Escalar: un objeto por sala y partición por identidad

Todo lo que hace poderoso a un Durable Object en tiempo real —ser único, tener un solo hilo, sostener el orden— es también, mirado del revés, su límite. Un objeto no se hace más grande porque llegue más gente: sigue siendo un hilo en una máquina, con su memoria y su presupuesto de cómputo. Por eso escalar aquí nunca significa engordar el objeto, sino multiplicarlo. La pregunta de diseño deja de ser cuántos servidores necesito y pasa a ser una mucho más interesante: cómo parto mi dominio en entidades con nombre para que ninguna cargue demasiado. Elegir bien esa partición es, casi siempre, la única decisión de escalado que tendrás que tomar.

La unidad de escala es el nombre

En un backend clásico, escalar tiempo real es un problema de infraestructura: más instancias del servidor de sockets, un bus de mensajes por medio para que las instancias se hablen entre sí, y una tabla que diga quién está conectado a cuál. Aquí no hay nada de eso, porque la propia identidad del objeto hace de repartidor. Cada sala, cada documento, cada partida es un nombre, y cada nombre es un objeto distinto con su hilo, su memoria y su almacén. Diez mil salas simultáneas no son diez mil conexiones apretadas en un proceso: son diez mil procesos diminutos, aislados entre sí, repartidos por la red.

export default {
  async fetch(request: Request, env: Env): Promise<Response> {
    const sala = new URL(request.url).searchParams.get("sala") ?? "general";
    // el nombre de la entidad es la unidad de escala
    const id = env.SALA.idFromName(`sala:${sala}`);
    return env.SALA.get(id).fetch(request);
  },
} satisfies ExportedHandler<Env>;

La palabra clave es aislamiento. Como dos salas no comparten memoria, ni hilo, ni almacén, tampoco comparten destino: una sala que recibe una avalancha ralentiza a sus propios miembros y a nadie más, y un fallo en el código que solo se dispara con cierto contenido tumba una entidad en vez de un servidor entero. Ese reparto del radio de impacto es una propiedad de escalado tan valiosa como el rendimiento, y se obtiene sin escribir una línea: viene de haber puesto un nombre a cada porción del mundo.

De ahí se sigue el antipatrón que hay que aprender a oler desde lejos: el objeto único. Es tentador crear una sola instancia que lo sepa todo —el registro global de usuarios en línea, el contador de todo el sistema, el enrutador central de mensajes— porque simplifica el código. Pero un objeto es un hilo, y un hilo es un cuello de botella con nombre propio: todo el tráfico del sistema se serializa en él, la latencia crece con la carga y no hay manera de repartirlo después sin rehacer el modelo. Si un objeto recibe tráfico proporcional al tamaño total de tu aplicación, está mal partido. La carga de cada objeto debe depender del tamaño de su entidad, no del de tu producto.

El abanico: por qué una sala grande duele

El coste de una sala no lo marca el número de conexiones, sino el producto de dos números. Si hay n participantes y cada uno envía m mensajes por segundo, el objeto procesa n por m mensajes entrantes, pero emite n por m por n salientes, porque cada mensaje se difunde a todos. El abanico es cuadrático en el número de participantes, y esa es la curva que decide si tu diseño aguanta.

Los números concretos aclaran la intuición. Cincuenta personas escribiendo un mensaje cada diez segundos son cinco entrantes y doscientos cincuenta salientes por segundo: trivial. Mil espectadores en un directo con cien comentarios por segundo son cien mil envíos por segundo desde un solo hilo: ya es un problema serio. Y una sala con decenas de miles de conexiones choca además con el techo de conexiones simultáneas que admite un objeto, del orden de decenas de miles. Antes de partir nada, calcula el abanico: es una multiplicación, y te dice si estás cerca del muro.

Cuando el abanico aprieta pero la sala todavía cabe, hay dos remedios previos a la partición, ambos baratos. El primero es agrupar: en vez de difundir cada mensaje al instante, acumula lo que llega durante un intervalo corto y emite un lote con una alarma, con lo que el abanico se calcula sobre lotes por segundo y no sobre mensajes por segundo. El segundo es adelgazar lo que viaja: difundir deltas en lugar de estados completos, y para datos de alta frecuencia —cursores, posiciones— quedarse con el último valor de cada emisor y descartar los intermedios, que nadie llegará a ver.

async webSocketMessage(ws: WebSocket, crudo: string): Promise<void> {
  this.pendientes.push(JSON.parse(crudo));
  // un solo abanico cada cien ms, sin importar cuantos mensajes lleguen
  if ((await this.ctx.storage.getAlarm()) === null) {
    await this.ctx.storage.setAlarm(Date.now() + 100);
  }
}

async alarm(): Promise<void> {
  if (this.pendientes.length === 0) return;
  this.difundir({ tipo: "lote", eventos: this.pendientes });
  this.pendientes = [];
}

Con esa sola alarma, mil mensajes por segundo en una sala de mil personas dejan de ser un millón de envíos y pasan a ser diez mil: dos órdenes de magnitud a cambio de cien milisegundos de retardo que nadie percibe en un chat. Antes de fragmentar nada, gasta siempre este cartucho.

Salas demasiado grandes: difundir en árbol

Si tras agrupar y adelgazar la sala sigue sin caber, hay que partirla, y la forma canónica es un árbol. La sala deja de ser un objeto y pasa a ser un coordinador con varios fragmentos: los clientes se reparten entre los fragmentos por un hash de su identidad, cada fragmento sostiene su porción de conexiones, y el coordinador solo habla con los fragmentos, nunca con los clientes.

const FRAGMENTOS = 16;

function fragmentoDe(usuario: string, sala: string): string {
  const h = [...usuario].reduce((a, c) => a * 31 + c.charCodeAt(0), 7);
  return `sala:${sala}:frag:${Math.abs(h) % FRAGMENTOS}`;
}

// en el coordinador: un envio por fragmento, no uno por cliente
async difundirEnArbol(mensaje: unknown, sala: string): Promise<void> {
  const trabajos = [];
  for (let i = 0; i < FRAGMENTOS; i++) {
    const id = this.env.FRAGMENTO.idFromName(`sala:${sala}:frag:${i}`);
    trabajos.push(this.env.FRAGMENTO.get(id).difundirLocal(mensaje));
  }
  await Promise.all(trabajos);
}

Hay una variante que conviene conocer porque cubre el caso más extremo, el de la retransmisión con cientos de miles de espectadores. Cuando los fragmentos pasan de unas pocas decenas, el coordinador vuelve a ser un cuello de botella —está haciendo un envío por fragmento— y la solución es añadir un nivel intermedio: el coordinador habla con un puñado de repetidores y cada repetidor con sus fragmentos. El árbol crece en profundidad en lugar de en anchura, y el número de envíos que hace cualquier nodo se mantiene pequeño mientras el total crece de forma exponencial con la altura.

El cambio de forma es el de siempre: un hilo que hacía n envíos pasa a hacer dieciséis, y cada fragmento hace n partido por dieciséis en paralelo, en dieciséis hilos distintos. El coste que pagas es real y conviene tenerlo presente: el orden global se relaja, porque dos fragmentos pueden entregar en instantes ligeramente distintos, y aparece un salto de red entre coordinador y fragmento. Por eso la partición se hace cuando hace falta y no antes: para un chat es aceptable, para un editor colaborativo donde el orden es el producto, casi nunca lo es.

flowchart TB
C[coordinador de la sala] --> F1[fragmento uno]
C --> F2[fragmento dos]
C --> F3[fragmento tres]
F1 --> A[clientes del fragmento uno]
F2 --> B[clientes del fragmento dos]
F3 --> D[clientes del fragmento tres]
style C fill:#a6e3a1,color:#11111b

Elegir la clave y el lugar

La decisión de fondo sigue siendo la clave de partición, y hay una prueba sencilla para validarla. Escribe cuánta carga tendrá el objeto más ocupado de tu sistema en el peor día que puedas imaginar; si esa cifra no depende del tamaño total de tu producto sino del de una sola entidad, la clave es buena. El documento, la sala, la partida y la persona suelen pasar la prueba. La organización entera, la región o el sistema global casi nunca la pasan, porque su carga crece con tu éxito.

Cuando una entidad natural resulta demasiado gruesa, refínala en vez de rendirte: un canal por tema dentro de un espacio de trabajo, un objeto por hoja en vez de por libro, un objeto por región del mapa en vez de por mundo. Y cuando resulta demasiado fina —millones de objetos con una conexión cada uno— agrupa hacia arriba, porque cada objeto tiene un pequeño coste fijo de despertar.

Vigila también el desequilibrio, que es el modo de fallo más común de una partición por lo demás razonable. Casi todos los dominios tienen entidades desproporcionadas: el canal general donde está la empresa entera, el documento que alguien compartió en público, la partida del torneo que ve todo el mundo. Una clave correcta en promedio puede seguir teniendo un objeto mil veces más cargado que la mediana, y ese objeto marcará tu peor latencia. Por eso el diseño se valida siempre contra la entidad mayor, no contra la típica.

// la primera peticion decide donde vive el objeto: acercalo a su gente
const id = env.SALA.idFromName(`sala:${sala}`);
const stub = env.SALA.get(id, { locationHint: "weur" });

Queda el lugar físico. Un objeto se crea cerca de quien lo invoca por primera vez y allí se queda, lo cual es óptimo cuando la primera petición viene de la misma región que el resto, y desafortunado cuando la crea un administrador desde otro continente. Con locationHint empujas esa decisión hacia la región que de verdad usará la sala. Recuerda que la pista solo cuenta en la creación, y que si tus participantes están repartidos por el mundo no hay ubicación perfecta: habrá una latencia base para los más lejanos, y lo que se optimiza entonces no es la distancia sino el número de viajes.

Con todo eso en la mano, el ejercicio final es escribir el presupuesto de un objeto: cuánto puede cargar antes de doler, y qué síntoma delata cada techo. No hay que memorizar cifras, sino saber cuál de estas cuatro dimensiones te limita primero, porque cada una pide un remedio distinto.