Why are correlation IDs useful, and how would you propagate them across an API and background worker?

Propagate correlation IDs across APIs and workers

Explains correlation IDs across request logs, dependency calls, queues, workers, and support investigations.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

A correlation id connects logs and telemetry from the same user request or business operation. The API reads or creates a correlation id at the boundary, puts it into logging scope, returns it in responses where useful, and passes it to downstream HTTP calls or queued messages. A worker then logs with the same correlation id when processing that message.

Full answer below

Practice focus

Request correlation, logging scopes, distributed tracing, message envelopes, dependency calls, and support diagnostics.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
Correlation is the difference between seeing many separate errors and following one business flow through the system.
A correlation id connects logs and telemetry from the same user request or business operation. The API reads or creates a correlation id at the boundary, puts it into logging scope, returns it in responses where useful, and passes it to downstream HTTP calls or queued messages. A worker then logs with the same correlation id when processing that message.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would distinguish correlation id from request id and message id. A request id identifies one HTTP request; a message id identifies one message; a correlation id ties the wider operation together. For queues, I would include correlation id and causation id in the message envelope. That makes it possible to answer: this failed email job came from which API call, tenant, user, or workflow?

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Generating a new correlation id in every layer.
Forgetting to pass correlation through queued work.
Putting sensitive user data inside the correlation id.
Using correlation id only in logs but not traces or support responses.

Why are correlation IDs useful, and how would you propagate them across an API and background worker?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue practice

Go deeper

Try a variant

Tech stacks

Skill areas

Suggest an improvement