El event loop ejecuta tu JavaScript en un solo hilo (single thread), por lo que cualquier cosa síncrona que tarde mucho lo bloquea — y mientras está bloqueado, Node no atiende ningún otro request, timer ni callback. El bloqueo casi siempre es trabajo ligado a la CPU (CPU-bound) o una API *Sync, nunca I/O asíncrono correctamente awaited.
*Sync) — fs.readFileSync, fs.writeFileSync, child_process.execSync, zlib.gzipSync. Esperan en línea en lugar de delegar el trabajo a libuv.map/sort/filter sobre arrays grandes, matemática de matrices, procesamiento de imagen/vídeo, parsear/serializar estructuras enormes.JSON.parse / JSON.stringify grandes — síncronos y O(n); un payload de varios MB congela el loop durante todo el parseo.crypto.pbkdf2Sync, bcrypt en modo sync, hashing de buffers grandes en el hilo principal.while (true), recursión sin límite, for sobre millones de elementos con trabajo por elemento.// Todo esto bloquea el loop — mientras tanto no se atiende ningún otro request:
const data = fs.readFileSync("big.json"); // I/O síncrono
const obj = JSON.parse(hugeString); // parseo grande
const hash = crypto.pbkdf2Sync(pw, salt, 1e6, 64, "sha512"); // criptografía síncrona
for (let i = 0; i < 1e9; i++) { /* CPU */ } // bucle ajustado
Envolver el trabajo de CPU en una función
asyncno ayuda —asyncsolo cede enawait; el cuerpo síncrono sigue ejecutándose hasta el final en el hilo del loop.
perf_hooks.monitorEventLoopDelay() o librerías como blocked-at; un retraso creciente significa que algo está acaparando el hilo.node --prof, clinic doctor/clinic flame, el CPU profile de Chrome DevTools para encontrar el frame síncrono caliente.*Sync (fs.promises.readFile, crypto.pbkdf2, zlib.gzip).worker_threads, un child process o una cola/servicio externo.setImmediate/await para que el loop pueda respirar entre lotes.const { Worker } = require("node:worker_threads");
// Descarga el hashing costoso para que el loop siga siendo responsivo.
const worker = new Worker("./hash-worker.js", { workerData: { pw, salt } });
En Node, una sola llamada bloqueante castiga a todos los clientes concurrentes, no solo al request que la causó — la latencia se dispara, los health checks expiran y el proceso parece "colgado" bajo carga. Los entrevistadores lo preguntan para ver si sabes nombrar los bloqueadores concretos (*Sync, JSON.parse grandes, criptografía síncrona, ReDoS, bucles de CPU), detectarlos con herramientas de medición del retraso del event loop y solucionarlos pasando a async o descargándolos en worker threads. Es con diferencia el fallo de rendimiento de Node más común en producción.
Una biblioteca de preguntas de entrevista de IT con respuestas detalladas — de Junior a Senior.
Donar