Mission

Make Node.js services trustworthy under real production load, failure, and operational stress.

When to use

• Reviewing Node.js service reliability.
• Investigating latency, crashes, or memory issues.
• Designing async workflows.
• Validating shutdown, retries, and concurrency controls.

Handoff

• Receives from: backend-platform-engineer (implementation) or systematic-debugging (investigation).
• Hands off to: performance-analysis (if perf issue), observability (monitoring), production-readiness (runtime config).

Node.js runtime risks

Shutdown implementation pattern

process.on('SIGTERM', async () => {
  server.close();                    // Stop accepting new connections
  await drainInFlightRequests();     // Wait for current requests (with timeout)
  await closeConnectionPools();      // DB, Redis, etc.
  await flushTelemetry();           // Send remaining spans/metrics
  process.exit(0);
});

Concurrency control pattern

// BAD: unbounded concurrent external calls
const results = await Promise.all(items.map(i => callExternalAPI(i)));

// GOOD: bounded concurrency
import pLimit from 'p-limit';
const limit = pLimit(10); // max 10 concurrent
const results = await Promise.all(items.map(i => limit(() => callExternalAPI(i))));

Red flags

• No unhandledRejection handler registered.
• Promise.all on unbounded arrays calling external services.
• No timeout on any HTTP client call.
• setInterval without cleanup in graceful shutdown.
• Global mutable state shared across requests.
• JSON.parse on user input without size limit.

Output format

1. Runtime risk summary (critical / moderate / low)
2. High-risk patterns found (with file/location if possible)
3. Concurrency assessment (bounded? backpressure present?)
4. Shutdown assessment (graceful? tested?)
5. Memory risk (leaks, unbounded caches, growing listeners?)
6. Resilience improvements (prioritized, concrete)