Concept questionEasy~5 min

Interview question

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?
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I would make correlation automatic in middleware and message wrappers so developers do not need to remember it manually. I would include correlation id in errors returned to clients and in support tools, but I would not use it as a secret. Distributed tracing can carry the same context through OpenTelemetry or Application Insights. The important behavior is that a support ticket, log query, trace, and dead-letter message can all meet on the same identifier.

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.

Red flagsCandidateRed flagsSignals that an interviewer may treat as risky.Open details

Details

Cannot follow a request into a worker.
No distinction between request id and correlation id.
No middleware or wrapper strategy.
No way for support to find the right logs.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

What belongs in a message envelope?
How would correlation help a dead-letter investigation?
Where would you expose correlation id to users or support?

Continue practice

Move to the linked follow-up, next path step, prerequisite, or deeper variant.

2 linked

Go deeper

Practice the next layer of the same subject.

Correlation IDs

Try a variant

Answer a similar question in a different context.

Lost Queue Correlation

Opening drill

Concept questionEasy~5 min

Interview question

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

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?
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I would make correlation automatic in middleware and message wrappers so developers do not need to remember it manually. I would include correlation id in errors returned to clients and in support tools, but I would not use it as a secret. Distributed tracing can carry the same context through OpenTelemetry or Application Insights. The important behavior is that a support ticket, log query, trace, and dead-letter message can all meet on the same identifier.

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.

Red flagsCandidateRed flagsSignals that an interviewer may treat as risky.Open details

Details

Cannot follow a request into a worker.
No distinction between request id and correlation id.
No middleware or wrapper strategy.
No way for support to find the right logs.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

What belongs in a message envelope?
How would correlation help a dead-letter investigation?
Where would you expose correlation id to users or support?

Continue practice

Move to the linked follow-up, next path step, prerequisite, or deeper variant.

2 linked

Go deeper

Practice the next layer of the same subject.

Correlation IDs

Try a variant

Answer a similar question in a different context.

Lost Queue Correlation

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

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