Cleaner Node.js Backend Code with Request-Scoped Context Storage

Imagine building a backend where every helper function in a long execution chain receives the same set of arguments—just to forward them to another function. You’re not using most of these parameters locally, but they clutter every signature, pollute your logs, and force you to refactor dozens of files when something changes. This pattern, now called parameter pollution, quietly introduces technical debt until your codebase grows and the pain becomes impossible to ignore.

I first encountered this issue while developing a clothing rental booking application. Early in the project, passing an orderId through three or four functions felt straightforward. But as features expanded, that single value had to traverse controllers, services, availability checkers, pricing calculators, and loggers. Functions that didn’t use the orderId directly were forced to accept it as a parameter simply because they sat in the middle of the chain. Every change—adding a new field or updating logging—required editing multiple function signatures across different files. The overhead wasn’t just noise; it was a maintenance nightmare.

The logging problem was particularly frustrating. To attach the orderId to every log entry, I had to include it as a parameter in every function, even those two levels deep in the call stack. Copy-pasting the same argument over and over felt redundant and violated the principle of keeping functions focused on their actual responsibilities.

The Hidden Costs of Manual Parameter Passing

Three interconnected issues made this approach unsustainable:

• Parameter Pollution: Functions accept arguments they don’t use, just to pass them forward. This violates the principle of least knowledge and makes code harder to understand.
• Tight Coupling: Adding new context data requires updating every function in the chain, creating a ripple effect that increases the risk of bugs and delays.
• Repetitive Boilerplate: Repeating the same parameters in function signatures and logging calls adds noise and reduces code clarity.

These problems are invisible in small projects. But once an application scales, they transform from minor annoyances into major obstacles to maintainability and performance.

AsyncLocalStorage: Solving Context Management in Node.js

The turning point came when I discovered AsyncLocalStorage, a feature from Node.js’s async_hooks module. Unlike traditional methods that rely on manually passing context through every function, AsyncLocalStorage provides a request-scoped storage mechanism that automatically propagates context across the entire asynchronous execution chain.

The concept is simple: you store context—like userId, orderId, or session data—once at the entry point of a request. From there, any function in the chain can access that context directly, regardless of how deep the call stack goes. Node.js tracks the async context internally, so the data is always available where it’s needed, without explicit passing.

Implementing Request-Scoped Context in Your Project

Setting up AsyncLocalStorage requires only two functions:

import { AsyncLocalStorage } from 'async_hooks';

// Create a storage instance for the entire request lifecycle
const requestContext = new AsyncLocalStorage();

/**
 * Wraps a function with the provided context.
 * All async operations inside fn will have access to this context.
 */
export function runWithContext(context, fn) {
  return requestContext.run(context, fn);
}

/**
 * Retrieves the current request context.
 * Returns an empty object if no context is set.
 */
export function getContext() {
  return requestContext.getStore() || {};
}

In your middleware or route handler—typically at the very start of the request lifecycle—you initialize the context:

// Express middleware example
app.use((req, res, next) => {
  const context = {
    orderId: req.headers['x-order-id'],
    userId: req.user?.id,
    requestId: req.id
  };
  runWithContext(context, next);
});

From that point on, any function—no matter how deep in the call stack—can retrieve the context using getContext(). For example, a logging utility:

function log(message, level = 'info') {
  const context = getContext();
  consolelevel;
}

No more passing orderId through every function. No more updating multiple signatures when requirements change. The context is available on demand, cleanly and efficiently.

The Benefits of Honest, Focused Functions

With AsyncLocalStorage, functions now only accept what they truly need to perform their tasks:

• Availability Checker: Receives only the data it uses to verify stock.
• Pricing Calculator: Accesses pricing rules and user tiers, not order metadata.
• Logger: Retrieves context independently, without being passed redundant arguments.

This shift leads to cleaner code, fewer bugs, and easier maintenance. Refactoring becomes safer, and onboarding new developers is faster because the context is transparent and centralized.

When AsyncLocalStorage Shines—and When It Doesn’t

AsyncLocalStorage is ideal for:

• Backend APIs handling user sessions or request-scoped data (e.g., e-commerce, SaaS platforms).
• Applications with deep call stacks where context must persist across async operations.
• Teams aiming to reduce boilerplate and improve code readability.

However, it’s not a silver bullet. Avoid using it for:

• Global state that should persist across requests (use a database or cache instead).
• Highly concurrent environments where context isolation is critical (always test under load).

A Lesson Learned Too Late

Small codebases hide design flaws. You don’t feel the pain of parameter pollution until complexity grows and the cost of change becomes prohibitive. By then, outdated patterns are deeply embedded, and refactoring feels overwhelming.

AsyncLocalStorage isn’t revolutionary—it’s pragmatic. It solves a real problem with minimal overhead. The only requirement is recognizing when your code is suffering from context pollution. Once you see it, you can’t unsee it. And that’s a good thing.

If you're currently passing the same parameter through three or more functions just to reach one inner function, this is your solution: store it once, read it anywhere, and let your functions focus on what they do best.