intermediate

Correlation IDs

Propagate request or workflow identifiers across frontend, API, queue, and worker boundaries so events can be joined.

A correlation ID (request ID, trace ID, or workflow ID) ties log lines, metrics exemplars, and support tickets to one user journey. Propagate it from the edge through APIs, queues, workers, and callbacks.

					// middleware
const requestId = req.headers['x-request-id'] ?? crypto.randomUUID();
res.setHeader('x-request-id', requestId);
req.log = logger.child({ requestId });

// enqueue
await queue.publish({ ...payload, requestId });
				

| Boundary | Mechanism | |----------|-----------| | HTTP | `x-request-id`, W3C `traceparent` | | Message queue | Message attributes / headers | | Frontend | Pass ID from BFF response to client error reports |

Generate at the trust boundary if missing; never regenerate mid-flow unless starting a new logical operation.

On interviews: where to create IDs, header naming, async continuation after HTTP returns, and joining frontend Sentry events with backend logs.

Common pitfalls: IDs dropped at queue boundaries; different header names per service; logging IDs without indexing them.

The trade-off is consistent propagation discipline versus slightly larger payloads and middleware complexity.

Checklist:

  • Create or accept ID at the edge.
  • Propagate through sync and async work.
  • Include ID in client error reports.
  • Index correlation fields in log stores.