Correlation ID vs Trace ID: What's the Difference?

A request can have a trace ID and a correlation ID at the same time. The two identifiers can describe different scopes.

A trace ID identifies one distributed trace. A correlation ID is an application-defined identifier used to group related work that may extend beyond a single trace.

For an order workflow:

Correlation ID: order-847291

Trace A: create order
Trace B: background payment processing
Trace C: send confirmation

The three traces can share the order correlation ID while retaining separate trace IDs.

A Trace ID Belongs to a Distributed Trace

In distributed tracing, a trace is made of spans that represent operations in one execution path.

Trace ID: 4bf92f3577b34da6a3ce929d0e0e4736

API request
├── Orders service
├── Database query
└── Payment request

Every span in that trace carries the same trace ID. Each span also has its own span ID.

Under W3C Trace Context, the traceparent header carries a trace ID, a parent ID, and trace flags between services. OpenTelemetry uses the same model: its SpanContext contains a TraceId and SpanId plus trace flags and trace state.

The trace ID lets a tracing backend group the spans into one trace.

A Correlation ID Is Defined by the Application

“Correlation ID” does not have one universal protocol definition equivalent to W3C Trace Context.

Teams use correlation identifiers to connect records that belong to a business operation or another logical unit of work:

order_id
checkout_id
job_id
case_id
workflow_id

The identifier can appear in logs, messages, database records, support tools, and trace attributes.

Its lifetime is determined by the application. An order ID might remain useful for months. A checkout correlation ID might exist only for the duration of a purchase attempt.

One Business Operation Can Contain Several Traces

The difference becomes clearer when work crosses asynchronous boundaries.

Customer submits order
        │
        ├── Trace A: HTTP request
        │
        ├── Trace B: queue consumer
        │
        └── Trace C: notification worker

Correlation ID: order-847291

Depending on instrumentation and propagation, asynchronous work can sometimes remain part of one trace. In other designs, later work starts a new trace.

A business identifier remains useful either way because it describes the application’s logical operation rather than the tracing system’s execution graph.

Trace IDs and Span IDs Have Defined Roles

A trace ID identifies the complete trace.

A span ID identifies one operation within that trace:

Trace ID
├── Span: POST /orders
├── Span: INSERT order
└── Span: POST /payments

OpenTelemetry represents trace IDs as 16 bytes and span IDs as 8 bytes. W3C Trace Context serializes those values as 32 and 16 lowercase hexadecimal characters respectively.

That makes examples such as a1b2c3 useful only as diagrams; production trace identifiers following these standards are longer and have defined validity rules.

Put Trace Context in Logs

Logs become easier to connect to traces when they include trace and span identifiers.

{
  "level": "error",
  "message": "Payment authorization failed",
  "trace_id": "4bf92f3577b34da6a3ce929d0e0e4736",
  "span_id": "00f067aa0ba902b7",
  "order_id": "order-847291"
}

OpenTelemetry recommends trace_id, span_id, and trace_flags as the field names when trace context is recorded in non-OTLP log formats.

The business identifier can live alongside them as an application field.

Do You Need a Separate Correlation ID?

A separate correlation ID is optional.

If one incoming request is the complete unit engineers need to investigate, the trace ID may provide enough correlation. Adding another opaque identifier can create more propagation and logging work without improving diagnosis.

A separate identifier becomes useful when the logical operation lasts longer than one trace or needs to be found outside the tracing system.

Examples include:

an order spanning HTTP requests and background jobs
a claim processed over several days
a batch job that starts many traces
a support case linked to several user actions

Often the best correlation value is an existing domain identifier such as order_id rather than a newly generated generic ID.

Propagate the Identifier Across the Work It Represents

A correlation ID only works if later components retain it.

For synchronous calls, it may travel in request metadata. For messaging, it can be copied into message attributes or the event payload. Background jobs can persist it with the job data.

Trace context has its own propagation rules and should use standard instrumentation where possible. Do not replace W3C trace propagation with an application correlation header and assume tracing tools will reconstruct the same graph.

Keep Trace and Application Identifiers Distinct

Using the same value for both can work in a simple system, but it ties two different lifecycles together.

A trace ID is governed by tracing semantics. A business correlation value is governed by application semantics.

Keeping those roles clear makes it easier to answer two different questions:

trace_id    → what happened in this execution path?
order_id    → what happened to this order across the system?

That distinction becomes especially useful once queues, scheduled jobs, retries, and long-running workflows enter the system.