Most Node.js apps start fast. The problem is they don't stay fast.
I've consulted on dozens of Node.js codebases for US startups and enterprise teams and the performance issues I find are almost never random. They follow the same patterns. The same architectural mistakes, made at the same stages of growth, by teams that were moving fast and didn't see the cliff coming.
This post breaks down the most common high-performance architecture mistakes I see, and what the fix actually looks like in practice.
Mistake 1: Treating Node.js Like a Multi-Threaded Runtime
Node.js runs on a single thread. This is the first thing every developer learns and the first thing they forget when they're under deadline pressure.
The consequence? Teams write blocking synchronous code inside request handlers. Things like:
// This blocks the entire event loop
const data = fs.readFileSync('./large-file.json');
const parsed = JSON.parse(data);
res.json(parsed);
When one request hits this handler, every other concurrent request waits. At low traffic this is invisible. At scale it becomes a full outage.
The fix: Everything I/O-related must be async. Use fs.promises, util.promisify, or stream-based APIs. Reserve Sync methods strictly for startup initialization, never inside a request lifecycle.
// Non-blocking version
const data = await fs.promises.readFile('./large-file.json', 'utf8');
const parsed = JSON.parse(data);
res.json(parsed);
Mistake 2: Not Using Worker Threads for CPU-Intensive Work
Node's event loop is excellent at I/O concurrency. It is terrible at CPU-intensive work. Image processing, PDF generation, cryptographic operations, large data transformations. Any of these running on the main thread will freeze your event loop.
Most teams handle this by either ignoring the problem or offloading to a separate microservice. The lighter-weight solution is worker threads:
const { Worker, isMainThread, parentPort, workerData } = require('worker_threads');
if (isMainThread) {
const worker = new Worker(__filename, {
workerData: { payload: largeDataset }
});
worker.on('message', (result) => {
// back on the main thread, event loop was never blocked
res.json(result);
});
} else {
// This runs in the worker thread
const result = heavyCPUOperation(workerData.payload);
parentPort.postMessage(result);
}
Worker threads share memory with the main thread (via SharedArrayBuffer) but run on separate OS threads, keeping your event loop free.
Mistake 3: No Connection Pooling on Database Clients
This one is subtle and brutal. Teams instantiate a new database connection per request or worse, per query without realizing it. At 10 requests/second this works fine. At 500 requests/second you hit Postgres's connection limit, and every new request hangs waiting for a connection that never comes.
Every database client your Node.js app uses should be configured with a connection pool:
// pg (PostgreSQL) with pooling
const { Pool } = require('pg');
const pool = new Pool({
host: process.env.DB_HOST,
database: process.env.DB_NAME,
max: 20, // max pool size
idleTimeoutMillis: 30000,
connectionTimeoutMillis: 2000,
});
// Reused across all requests — not recreated each time
const result = await pool.query('SELECT * FROM users WHERE id = $1', [userId]);
The pool is created once at app startup. Requests borrow a connection from the pool and return it when done. Under the hood, your app maintains 20 live connections instead of spinning up thousands.
Mistake 4: Ignoring Memory Leaks Until They Crash Production
Node.js apps are long-running processes. Unlike a PHP request-response cycle that tears everything down after each request, a Node.js server holds memory across its entire lifetime. Event listener leaks, closure references, growing caches. These accumulate invisibly until your memory usage doubles, then triples, then your container gets OOM-killed at 2am.
The two most common sources of leaks I find:
Uncleaned event listeners:
// Leak: new listener added every time this function runs
function setupHandler(emitter) {
emitter.on('data', processData); // grows unbounded
}
// Fix: remove the listener when done, or use .once()
function setupHandler(emitter) {
emitter.once('data', processData);
}
Growing in-memory caches without eviction:
// Leak: this Map grows forever
const cache = new Map();
app.get('/user/:id', async (req, res) => {
if (!cache.has(req.params.id)) {
cache.set(req.params.id, await fetchUser(req.params.id));
}
res.json(cache.get(req.params.id));
});
Use a proper LRU cache with a size limit (lru-cache npm package), or better yet, use Redis so your cache lives outside the Node.js process entirely.
Mistake 5: No Clustering or Load Distribution
A single Node.js process uses one CPU core. If your server has 8 cores, you're leaving 7 of them idle unless you cluster:
const cluster = require('cluster');
const os = require('os');
if (cluster.isPrimary) {
const numCPUs = os.cpus().length;
for (let i = 0; i < numCPUs; i++) {
cluster.fork(); // spawn one worker per CPU core
}
cluster.on('exit', (worker) => {
console.log(`Worker ${worker.process.pid} died, respawning`);
cluster.fork();
});
} else {
// Each worker runs the Express app independently
require('./app');
}
In containerized environments (Kubernetes, ECS), clustering is often handled at the orchestration layer. You run multiple single-core containers instead. But in either case, you need to account for it architecturally, not leave it to chance.
Mistake 6: Synchronous JSON Parsing of Large Payloads
JSON.parse() is synchronous and blocks the event loop proportional to the payload size. Parsing a 10MB JSON body in a webhook handler? That's hundreds of milliseconds of event loop blockage per request.
For large payloads, stream-parse instead of buffering:
const { pipeline } = require('stream');
const JSONStream = require('JSONStream');
app.post('/bulk-import', (req, res) => {
const results = [];
pipeline(
req,
JSONStream.parse('*'),
async function* (source) {
for await (const record of source) {
results.push(await processRecord(record));
}
},
(err) => {
if (err) return res.status(500).json({ error: err.message });
res.json({ imported: results.length });
}
);
});
The Architectural Pattern That Ties This Together
All of these mistakes share a root cause: treating Node.js like a synchronous, multi-threaded runtime when it's neither. The mental model that fixes everything:
Your Node.js process is a traffic director, not a worker. Its job is to receive I/O, delegate work (to databases, queues, worker threads, external services), and respond. Any time your main thread is doing actual work: Parsing, computing, transforming. You're using it wrong.
The teams I've seen build truly high-performance Node.js systems all internalize this. The event loop stays clear. Heavy work goes to workers or queues. All I/O is pooled and async. Memory is bounded and monitored.
If you're building a Node.js-backed SaaS product and want an architectural review before you hit these walls in production, I work with US-based startups and enterprise teams on exactly this kind of problem. You can see my full-stack development approach at waqarhabib.com/services/full-stack-development.
Originally published at waqarhabib.com
Top comments (0)