Node.js
One slow function should not take the whole service down
Our engineers run Node behind a real-time trivia platform clustered across servers and a clinical matching API. Node's strength is holding thousands of open connections. Its trap is the one call that blocks them all.
What you are getting
4 things that decide this
- 01Senior engineers with Node running in production, including a Socket.IO platform clustered across several servers with Redis behind it.
- 02They know what belongs on the event loop and what belongs on a worker. That single judgement is most of Node performance.
- 03You interview each engineer yourself, using your own process, and a no needs no justification.
- 04Every line, plus the deployment config, belongs to you from the first commit.
What a Node developer actually does here
Node holds a lot of connections cheaply. That is the reason to pick it, and the reason it fails in a specific way.
Elevent runs live multiplayer trivia on Node 22 and Express with Socket.IO, using a Redis adapter so sockets work across more than one server. Without that adapter a second server means two players in the same game stop seeing each other. TrialTriage uses NestJS with Redis job queues, so heavy matching work leaves the request path entirely.
Both builds make the same call in different clothes. Decide early what the user waits for, and push everything else somewhere it cannot block the loop.
The judgements that decide a Node service
Nothing heavy on the loop
CPU work moved to a queue or a worker thread. One synchronous parse of a large file will stall every other request on that process.
Sockets that survive a second server
Real-time state shared through Redis rather than held in one process memory. Otherwise scaling out quietly breaks the feature.
Errors that do not kill the process
Rejected promises handled, not left to crash the worker. An unhandled rejection takes down every connection that process was holding.
Structure that survives growth
Modules and dependency injection, as in NestJS, so a service does not become one file of routes that nobody wants to open.
Streams for anything large
Files and exports streamed rather than loaded into memory. A report that works at a thousand rows and dies at a million is nearly always this.
- ConnectionCheap, thousands of them
- Event loopSingle thread, keep it free
- I/O waitNon-blocking, this is the win
- CPU workMove it off, or it stalls
- Shared stateRedis, so servers agree
Box four is where most Node performance problems live. Adding servers does not help when each one is blocked on the same kind of work.
Real-time and queue-backed services
“Their attention to detail, quality of employees, and work ethic were outstanding.”
Nicolas de Quesada · CEO, Lexpair
How hiring works
- 01
Tell us what has to stay live
A free call about the traffic, the connections and what users are waiting on. If your load would be simpler in another runtime, we say so.
- 02
Meet the engineers
We shortlist people who have scaled a Node service past one process, and you interview them your own way.
- 03
They embed
Your repository, your standups, your on-call rotation. One of our engineers owns the service and its behaviour under load.
- 04
They hand over
Tests, load figures from your own environment, and a written note on what must not go on the event loop. Some clients keep us on for the on-call instead, under a service level we agree.
Stack
Runtime
Around it
Practices
Bring us the service that falls over under load
Show us the traffic and what users wait on. The scoping call is free, and you will leave knowing whether you need better code or more machines.
01Should we use Express or NestJS?
Express suits a small service where you want no opinions imposed. NestJS suits a product several engineers will work on for years, because the structure is decided for you and arguments about layout stop. TrialTriage uses NestJS for exactly that reason. We recommend one on the call rather than defaulting to whichever we used last.
02Can Node handle our real-time traffic?
Usually yes, and the limit is rarely the runtime. Elevent runs live multiplayer sessions on Node across clustered servers with Redis coordinating them. The failure people blame on Node is nearly always one blocking call or socket state trapped in a single process.
03Do they write TypeScript or plain JavaScript?
TypeScript by default on anything that will be maintained. It catches the class of mistake that otherwise reaches production as an undefined value at midnight. If your codebase is plain JavaScript, they work in it as it is rather than converting it on their own initiative.
04Can they work on a Node service we already run?
Yes, and that is the more common request. They read what exists, ship a small change to prove the pipeline works, then take on the harder parts. Nothing gets rewritten because it looks unfamiliar.
05How do you handle background jobs?
On a queue, with retries and a place failures are parked. Redis-backed queues are the usual choice, as on TrialTriage, so heavy work never sits in the request path. A job that can run twice without harm is a design decision made early, not a patch after a duplicate charge.
06What makes one Node engagement cost more than another?
The number of moving parts, mostly. A single API is straightforward; a real-time product with sockets, queues and several servers has more places to be wrong and more to test. Scoping calls are free. Where we have to read an existing service before answering, a paid two-week diagnostic ends with a fixed price.
