Por qué un proceso Node de larga vida gana a serverless cuando el producto es la conexión

Serverless es muy difícil de batir para cargas de petición-respuesta: la función despierta, hace un trabajo, devuelve y pagas por milisegundos. Un producto en tiempo real no es esa carga. Su rasgo definitorio es la conexión que permanece abierta, y el modelo económico de las funciones se apoya justo en lo contrario: nada permanece abierto. Sobre esa frase se sostiene la decisión que cuenta el ingeniero Yaseen Khatib en su blog, donde explica por qué para un panel en vivo con miles de conexiones empujando telemetría montó un proceso Node de larga vida en lugar de repartir el trabajo en invocaciones.

Qué compra el proceso persistente

El estado deja de viajar. Un registro de suscripciones, una caché o una ventana de limitación de tasa viven en memoria y se leen en un par de instrucciones; en serverless cada uno de esos elementos se convierte en un viaje de ida y vuelta a Redis, en cada mensaje, para siempre. El fan-out a 5.000 suscriptores es recorrer un Map. El mismo reparto a través de una pasarela gestionada son 5.000 invocaciones facturables.

También gana el control de flujo. El socket avisa cuando el cliente no puede seguir el ritmo; una función sin estado no sabe que hay un consumidor ahogándose porque nunca lo ve dos veces. Y lo que se establece una sola vez al arrancar —pool de conexiones, serializadores compilados, sentencias preparadas— no se vuelve a levantar en un arranque en frío delante de un usuario que espera. El orden dentro de una conexión sale gratis: los mensajes de un mismo cliente llegan a un mismo proceso en orden. Con invocaciones independientes eso exige una cola y números de secuencia que alguien mantiene.

La factura es el argumento que suele decidir. Comparar precio por invocación contra precio por hora favorece a serverless. Pero un producto en tiempo real factura por minutos de conexión y por mensajes. Diez mil conexiones ociosas en un proceso persistente cuestan descriptores de fichero y algo de memoria; en una pasarela WebSocket gestionada son una línea que crece mientras los usuarios no hacen nada.

Lo que se asume a cambio

Khatib lo enumera sin adornos. Desplegar sin tirar conexiones obliga a drenar: dejar de aceptar, esperar a que los clientes reconecten contra la instancia nueva y salir. Escalar es una decisión suya y no algo que ocurre solo. Un proceso que se cae se lleva sus conexiones, así que las comprobaciones de salud y los reinicios pasan a ser responsabilidad propia. Y las fugas de memoria se quedan, no desaparecen a los 200 ms. Calcula ese trabajo en alrededor de una semana de infraestructura, pagada una vez por él frente a la latencia y el coste que paga cada usuario en cada sesión.

Para todo lo demás sigue eligiendo funciones sin dudar: la API REST que envuelve el núcleo en tiempo real, tareas programadas, receptores de webhooks, procesado de imágenes, cualquier cosa con picos y sin estado. El límite, dice, está exactamente donde el estado deja de importar.

El texto no trae mediciones ni comparativas de latencia o coste con cifras: es el relato de una decisión, no un banco de pruebas. Lo transferible es el método. Localizar la restricción que gobierna el producto —aquí, que las conexiones siguen abiertas— y comprobar la respuesta por defecto contra ella antes de aceptarla. Casi siempre el valor por defecto aguanta y la conversación dura cinco minutos.