We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
This idea carries a full system design question on its own. Each walks through the full answer.
System Design Masterclass · Observability Monitoring
Free preview: the first 2 parts of this 7-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Observability Monitoring
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
It is easy and good
“It is really nice and good Please join the course”
A customer places a single order on an e-commerce platform. Behind the scenes, that one click triggers a cascade: validate the cart, reserve inventory, process payment, generate an invoice, send a confirmation email, update the recommendation engine, publish an analytics event, notify the warehouse, update the loyalty points, and send a push notification. Across 12 services, 47 distinct events fire, many of them asynchronous.
The original request ID tracked the synchronous chain beautifully. But the email service received a message from a queue, not an HTTP request. The warehouse notification arrived via a webhook. The analytics update came through an event stream. None of these inherited the original request ID through HTTP headers because they weren't HTTP requests.
A correlation ID is a broader concept than a request ID. It's an identifier that ties together everything related to a single business action, even when that action spans synchronous calls, asynchronous messages, scheduled jobs, and webhook callbacks. The request ID says "this is one HTTP request." The correlation ID says "this is one user action, regardless of how many systems it touched or how many protocols it crossed."
| Aspect | Request ID | Correlation ID |
|---|---|---|
| Scope | One request chain | One business action, any number of requests |
| Generated when | HTTP request enters the system | Business action starts |
| Propagated via | HTTP headers | Headers, message metadata, event payloads |
| Survives async? | Not inherently | Yes, that's its purpose |
| Example | req_abc123 | corr_order_8834 |
In practice, many teams use both. The correlation ID ties together the full business flow. Individual request IDs identify each HTTP call within that flow. A single correlation ID might encompass 5 different request IDs if the business action involved 5 separate HTTP interactions.
Implementation: When the initial request arrives, generate both a request ID and a correlation ID. The request ID stays with the HTTP chain. The correlation ID gets embedded in message payloads, event metadata, job parameters, and any other mechanism that triggers downstream work.
When the email service picks up a "send confirmation" message from the queue, it reads the correlation ID from the message body, includes it in its logs, and if it makes HTTP calls (to a template service, for example), propagates both the correlation ID and a new request ID for that specific HTTP chain.