performance-observabilityAnswer last reviewed July 2026

In Node, how does distributed tracing actually follow a request across all those async boundaries? And what does that machinery cost you at runtime?

A strong answer explains how `AsyncLocalStorage` carries context across async boundaries and what that machinery actually costs at runtime

What an AI-prepared candidate might say

So tracing works by giving each request a trace ID and carrying that ID through all the work done for it, including across service calls in headers. The tricky part inside a Node process is that the work happens across async callbacks, so a normal local variable doesn't survive. Node has AsyncLocalStorage, which stores data that stays associated with the current asynchronous execution context, so any code running as part of that request can read the trace context without passing it around explicitly. Under the hood it uses async_hooks to track async operations, I believe, and that tracking adds overhead to every async operation, so tracing isn't free. Turning it on can measurably slow the app down. That's why you sample, only tracing a fraction of requests. And between services the trace context travels in HTTP headers, there's a standard, W3C Trace Context, so the trace continues in the next service.

Senior
Locked

How `AsyncLocalStorage` gets context across awaits with zero manual threading, the `async_hooks` machinery underneath, and where that per-operation cost really comes from.

Unlock the depth
Staff
Locked

How to decide what's worth tracing and at what sampling rate once you know the runtime cost, carry context across service boundaries, and measure the overhead you actually added.

Unlock the depth
Follow-up chain
In Node, how does distributed tracing actually follow a request across all those async boundaries? And what does that machinery cost you at runtime? | NodeBook