Event Loop vs Crypto Module

Why it exists

Node.js runs application code on a single thread driven by an event loop. Some operations, particularly password hashing algorithms like pbkdf2 and scrypt, are deliberately slow and CPU intensive by design, that slowness is what makes them resistant to brute force attacks. Running that work directly on the same thread that also handles every incoming request would freeze the whole server for the duration of each hash. Node's crypto module offers asynchronous variants specifically to avoid that.

The mental model

Picture a single cashier, the event loop, serving a line of customers, incoming requests. Most orders are quick. One customer orders something that takes real effort to prepare, a password hash. The synchronous version has the cashier personally stop and grind through that order alone while the whole line waits behind them. The asynchronous version hands the order to back room kitchen staff, the thread pool, so the cashier keeps serving everyone else and only steps back in once the order is ready.

How it works

Node's crypto module wraps OpenSSL. Asynchronous methods such as crypto.pbkdf2 and crypto.scrypt queue their computation onto libuv's threadpool, a fixed size group of worker threads, four by default, configurable through the UV_THREADPOOL_SIZE environment variable, that runs outside the main JavaScript thread. When the work finishes, a completion callback gets scheduled back onto the event loop. The synchronous counterparts, pbkdf2Sync and scryptSync, run directly on the main thread and return only once finished, during which no timers, no I/O callbacks, and no other requests can be processed at all.

When it matters

This matters anywhere a Node server verifies passwords or derives keys under concurrent load. Using a sync crypto call inside a request handler means every other in flight request, including unrelated health checks, stalls until that one hash finishes. It also matters because the threadpool is shared with filesystem operations and DNS lookups, so heavy async crypto usage can starve unrelated I/O if the pool is too small for the load.

A concrete example

A login endpoint calls pbkdf2Sync with 100,000 iterations, taking around 100 milliseconds per call. Under 50 concurrent login attempts, the last user in line waits nearly five seconds just for earlier hashes to finish, since each one blocks the entire process. Switching that same endpoint to the callback based crypto.pbkdf2 lets the 50 hashes run concurrently across the thread pool, so unrelated requests keep responding normally the whole time.