Build fluency in the vocabulary of tying logs from many services back to one originating request.
0 / 5 completed
1 / 5
At standup, a dev mentions attaching a unique identifier to a request at its entry point and propagating it through every downstream service call, so logs from different services can be tied back to that same request. What is this identifier called?
A correlation ID is a unique identifier attached to a request at its entry point and propagated through every downstream service call, letting logs from disparate services be tied back to that same original request. A timestamp recorded independently by each service is ambiguous under concurrent traffic, since many requests can share nearly the same timestamp. This shared identifier is what makes tracing one request's full path through a distributed system actually feasible.
2 / 5
During a design review, the team wants the correlation ID carried not just through a synchronous service call but also through an asynchronous message placed onto a queue. Which capability supports this?
Propagation of the correlation ID across both a synchronous service call and an asynchronous queue message ensures the same identifier survives the entire request's journey, however it travels between services. Propagating it only through synchronous calls loses the connection the moment a request's processing crosses into an async, queue-based boundary. This broader propagation is what keeps a correlation ID useful across a genuinely distributed, mixed synchronous-and-asynchronous system.
3 / 5
In a code review, a dev notices every structured log line emitted by a service includes the correlation ID as one of its fields, rather than logging it only occasionally. What does this represent?
Including the correlation ID as a consistent field in every structured log line means every single log entry related to a request can be found and grouped together, no matter which service emitted it. Logging it only occasionally leaves gaps where a log line can't be tied back to its originating request at all. This consistent inclusion is what lets a team reconstruct a request's complete path across a distributed system's logs.
4 / 5
An incident report shows a production bug took hours to diagnose because one service in the call chain dropped the correlation ID header, breaking the ability to trace that specific request end-to-end across the remaining services. What practice would prevent this?
Enforcing correlation ID propagation consistently across every service in the call chain, including through an asynchronous boundary, prevents exactly the kind of broken trace this incident describes. Allowing any individual service to drop it without consequence leaves the entire tracing effort fragile, since one gap breaks the chain for every service downstream of it. This consistent enforcement is what makes a correlation ID reliably useful during an actual production investigation.
5 / 5
During a PR review, a teammate asks why the team propagates a dedicated correlation ID through every service instead of just matching up log entries across services using their recorded timestamps. What is the reasoning?
Timestamp-based matching is ambiguous under concurrent traffic, since many unrelated requests can share nearly identical timestamps, especially in a busy production system. A correlation ID uniquely ties every related log line to one specific request regardless of how many other requests are happening at the same moment. The tradeoff is the discipline needed to ensure every service in a call chain actually propagates the identifier correctly, rather than silently dropping it.