Consigna y contexto
Un servicio de colaboración en tiempo real cuenta con decenas de miles de conexiones de larga duración que utilizan una biblioteca de WebSocket de terceros. Node.js 22.4 marca WebSocket como estable, y el equipo desea reducir dependencias. Aborda compatibilidad, ciclo de vida, contrapresión (backpressure), autenticación, observabilidad y reversión (rollback).
Qué evalúa el entrevistador
Comprueban si distingues la estabilidad de una API de su madurez en producción, y si puedes diseñar límites, heartbeats, contrapresión en difusiones (broadcasts), apagado elegante (graceful shutdown) y una migración gradual y medible.
Preguntas para aclarar
Pregunta sobre el protocolo del cliente, soporte de proxies, tamaño de mensaje, pico de conexiones, renovación de credenciales, distribución entre nodos (cross-node fan-out), reconexiones y fallas regionales. Identifica el comportamiento de las extensiones y las garantías que la biblioteca actual debe mantener.
Respuesta de 30 segundos
“Crearía una matriz de diferencias de API y protocolo y verificaría Node 22.4+, proxies y clientes. Cada conexión recibe autenticación, heartbeat, límites de inactividad y de tamaño de mensaje; las difusiones usan colas limitadas para la contrapresión, y el apagado drena el tráfico tras rechazar nuevas conexiones. Haría shadowing y canary, compararía el éxito del handshake, desconexiones, latencia P95, memoria y CPU, y mantendría un interruptor hacia la implementación de terceros para una reversión rápida.”
Análisis detallado paso a paso
Verificar el entorno de ejecución y el protocolo
La documentación de Node indica que WebSocket ya no es experimental a partir de v22.4.0. Fija la versión de Node y verifica handshakes, extensiones, tiempos de espera (timeouts) de proxies y configuraciones de TLS.
Diseñar el ciclo de vida de la conexión
Autentica y autoriza al momento de la conexión, luego establece políticas de inactividad, heartbeat y códigos de cierre. Durante el reinicio, deja de aceptar conexiones, drena y envía una sugerencia de reconexión.
Manejar la contrapresión y el tamaño
Asigna a cada conexión una cola de envío limitada. Al alcanzar el límite, descarta mensajes reconstruibles, degrada el servicio o desconecta a los consumidores lentos. Limita los frames y los mensajes agregados para que un solo cliente no agote la memoria ni el event loop.
Aplicar autenticación y autorización
Valida una credencial de corta duración durante el handshake y vuelve a verificar los permisos de inquilino (tenant) y recursos para mensajes sensibles. Una renovación fallida cierra la conexión y exige una reautenticación.
Escalar a través de múltiples nodos
Mantén el estado de la conexión de forma local y enruta los eventos a través de un bus de mensajes. Asigna a las suscripciones una versión o cursor para que las reconexiones puedan reproducir los vacíos en lugar de retransmitir todo nuevamente.
Canary, monitoreo y reversión
Habilita internamente y para el 1% del tráfico. Compara fallas de handshake, supervivencia de conexiones, reconexiones, mensajes descartados en cola, latencia P95, memoria y CPU. Mantén la implementación antigua disponible mediante un interruptor y revierte ante regresiones de protocolo o recursos.
Respuesta modelo
No reemplazaría la biblioteca únicamente porque la API sea estable. Fijaría Node 22.4+, verificaría la compatibilidad de proxies y clientes, y luego agregaría autenticación en handshake, heartbeat, tiempo de espera por inactividad, límites de tamaño y colas de envío acotadas. Los nodos comparten eventos y cursores, no el estado de las conexiones, y las reconexiones reproducen los vacíos. Un canary compara el éxito del handshake, desconexiones, reconexiones, descartes en cola, P95, memoria y CPU, mientras la ruta antigua sigue disponible para reversión.
Errores comunes
Equiparar una API estable con un reemplazo completo
La biblioteca puede proporcionar extensiones, compresión o comportamientos de reconexión específicos. Documenta y prueba cada diferencia.
Omitir una política para consumidores lentos
Las colas sin límite agotan la memoria. Limita la cola, descarta mensajes reconstruibles o desconecta al cliente.
Autorizar solo en el handshake
Los permisos pueden ser revocados durante una conexión prolongada. Las acciones sensibles necesitan verificaciones a nivel de mensaje o una versión de política.
Matar conexiones abruptamente durante el reinicio
Eso provoca una tormenta de reconexiones. Drena el tráfico, aplica jitter a las reconexiones y usa códigos de cierre explícitos.
Preguntas de seguimiento
¿Cómo controlas una tormenta de reconexiones?
Devuelve un motivo de cierre claro, implementa retroceso exponencial (exponential backoff) con jitter en los clientes y limita la tasa (rate-limit) por IP, inquilino y cuenta en el servidor.
¿Cuándo mantendrías la biblioteca de terceros?
Consérvala cuando las extensiones requeridas, la compresión, la compatibilidad con proxies o la telemetría madura no se igualen y el valor de reemplazarla sea bajo; registra el límite de la evaluación.
¿Cómo pruebas la contrapresión?
Inyecta clientes lentos y ráfagas de difusiones, luego observa los límites de cola, el comportamiento de descarte, el retraso del event loop y las curvas de memoria.
¿Cómo preservas el orden a través de los nodos?
Asigna un cursor monótono por flujo de suscripción y transporta versiones a través del bus; los clientes detectan vacíos y solicitan su retransmisión.