Imagine you send a letter through five different post offices before it reaches its final destination. If the letter goes missing, how do you find out which post office lost it? You would need some kind of tracking number written on the envelope — something that stays the same at every stop. A correlation ID is exactly that tracking number, but for computer requests instead of letters.

A correlation ID is a unique piece of text — usually a random string like 7f3a9e21-4b6d-4c2a-9f11-8e2d5c7a10bb — that gets attached to a request the moment it enters a system, and then travels along with that request as it passes through every service, queue, database call and log line involved in handling it. Its only job is to answer one question later: “which of these thousands of log lines all belong to the same original request?”

To understand why this idea became so important, it helps to look at how software architecture changed over the last two decades. In the early 2000s, most business applications were built as a single large program, often called a monolith. A monolith runs as one process on one or a few servers. When something went wrong, an engineer could open a single log file, scroll up and down, and see the entire story of a request from start to finish, because everything happened in one place.

Then came Service-Oriented Architecture (SOA) in the mid-2000s, and later microservices in the 2010s, popularised heavily by companies like Netflix, Amazon and Uber. Instead of one giant program, an application became dozens or even hundreds of small, independent services — an “Order Service,” a “Payment Service,” an “Inventory Service,” a “Notification Service,” and so on — each running on its own servers, each writing its own separate log files.

This split brought real benefits: teams could work independently, services could scale separately, and a failure in one service wouldn’t necessarily crash the whole system. But it created a brand-new headache. A single user action, like “place an order,” might now touch ten different services. If something failed, an engineer could no longer just open one log file. They would have to guess which of the ten services’ logs to look at, and even then, they had no easy way to know which specific lines, out of millions, belonged to that one particular order.

The correlation ID pattern grew out of this exact pain point. Distributed systems engineers, borrowing ideas from older telecommunication and networking systems (where “call IDs” and “transaction IDs” had long been used to trace a phone call or a bank transaction through multiple switches), began attaching a single unique identifier to every incoming request. That identifier would then be passed forward — in HTTP headers, in message queue metadata, in log statements — so that no matter how many services touched the request, every log line related to it could be found instantly with one search.

Today, correlation IDs are considered a foundational, almost non-negotiable practice in distributed systems, cloud-native architecture and microservices. They are one of the “three pillars of observability” building blocks (alongside logs, metrics and traces) and are supported natively or through libraries in nearly every modern framework — Spring Boot, Express.js, ASP.NET Core, Django and more. Distributed tracing systems like Zipkin, Jaeger and OpenTelemetry are essentially a more powerful, standardised evolution of the same basic idea.

2.1 · A single request, many services

Say a customer named Aisha clicks “Buy Now” on a shopping app. Behind that one click, the following might happen:

1. The API Gateway receives the HTTP request from Aisha’s phone.
2. It forwards the request to the Order Service, which creates a new order record.
3. The Order Service calls the Inventory Service to check if the item is in stock.
4. The Order Service calls the Payment Service to charge Aisha’s card.
5. The Payment Service calls an external Bank API.
6. Once payment succeeds, the Order Service publishes a message to a Notification Service via a message queue.
7. The Notification Service sends Aisha a confirmation email and SMS.

That is seven different components, likely running on seven different sets of machines, each writing its own log files. Now imagine Aisha calls customer support and says, “I was charged twice, please help.” An engineer now has to answer: what actually happened, in what order, across all seven components, for this one specific order?

2.2 · Without a correlation ID

Without any shared identifier, the engineer’s job becomes extremely difficult. They might know Aisha’s email address or approximate timestamp, but:

• Timestamps across servers can be slightly out of sync (this is called clock drift), so “search logs around 3:04 PM” is unreliable.
• Many customers may be placing orders at the exact same second, so searching by time alone returns hundreds of unrelated log lines.
• Each service may log the order using a different internal identifier (an order ID, a payment reference number, a cart ID) with no obvious link between them.
• The engineer must manually open logs from seven different systems, one at a time, and try to piece together a timeline by eye. This can take hours, especially under pressure during an active incident.

2.3 · The motivation behind the solution

The fix is conceptually simple: give every incoming request one unique ID the moment it arrives, and make every single service, log statement and outgoing call carry that same ID forward. Now the engineer’s job becomes trivial — search all logs, across all systems, for that one ID, and get every related line back, in order, instantly.

This idea satisfies three important goals at once:

3.1 · What exactly is a correlation ID?

A correlation ID is a short, unique, opaque string generated once per logical request and then propagated (passed along) unchanged through every component that participates in handling that request. “Opaque” means the string itself carries no business meaning — it is not an order number or a customer ID, it is purely a tracking label. It is usually a UUID (Universally Unique Identifier), a 128-bit value typically written as 32 hexadecimal characters separated by hyphens, such as 550e8400-e29b-41d4-a716-446655440000.

3.2 · Why UUIDs?

A UUID is popular for correlation IDs because it can be generated independently, on any machine, without needing to ask a central server “give me the next available number.” The mathematical odds of two randomly generated UUIDs colliding (being the same) are astronomically small — small enough that engineers treat them as effectively unique across an entire company’s systems, for practically forever. This matters enormously in distributed systems, where you cannot afford to have a single central counter that every server must contact before creating an ID, since that would become a bottleneck and a single point of failure.

3.3 · Correlation ID vs related terms

Beginners often mix up a few closely related terms. Here is a clear breakdown.

3.4 · Where correlation IDs are used

• HTTP APIs — passed as a request header, commonly X-Correlation-ID or X-Request-ID.
• Message queues — passed as message metadata in systems like Kafka, RabbitMQ and Amazon SQS.
• Logging frameworks — injected into every log line automatically using a mechanism called MDC (explained later).
• Distributed tracing systems — the backbone identifier tying together spans in Jaeger, Zipkin and OpenTelemetry.
• Background jobs and batch processing — attached to scheduled or asynchronous tasks so their execution can be traced later.
• Customer support tools — sometimes shown to end users (e.g., “Please share this reference ID with support: ABC-123”) so a human agent can locate the exact technical trail.

3.5 · Key properties of a good correlation ID

4.1 · The generator

Some component has to create the correlation ID the very first time a request enters the system — usually at the outermost edge, such as an API Gateway, a load balancer, or the very first web server that receives the client’s request. This is called the entry point or ingress.

4.2 · The carrier (propagation mechanism)

Once generated, the ID needs a “vehicle” to travel in as it moves from one process to another. Depending on the communication style, the carrier differs:

4.3 · The context holder (in-process storage)

Inside a single running service, once a thread receives a request carrying a correlation ID, that ID needs to be accessible to every part of the code that might want to log something — without the programmer having to manually pass the ID as an extra parameter into every single function. This is solved using a mechanism called MDC (Mapped Diagnostic Context) in Java logging frameworks like SLF4J and Logback, or ThreadLocal storage more generally, or newer async-safe context mechanisms in reactive and asynchronous frameworks.

4.4 · The logger integration

The logging framework must be configured so that every single log statement automatically includes the current correlation ID, without the developer typing it manually each time. This is typically done once, centrally, in the logging configuration (for example, in Logback’s logback.xml pattern layout).

4.5 · The aggregator (centralised log storage)

Correlation IDs are only useful if logs from every service actually land in one searchable place. This is where centralised logging platforms come in — tools like the ELK Stack (Elasticsearch, Logstash, Kibana), Splunk, Datadog or Grafana Loki. Each service ships its logs to this central store, and an engineer can then search “correlation_id: 7f3a9e21…” and instantly see every relevant line from every service, sorted by time.

4.6 · Putting the components together

None of these five pieces work alone. The generator creates the ID, the carrier moves it across network boundaries, the context holder keeps it available inside each process, the logger integration stamps it onto every log line, and the aggregator lets a human search across all of it at once. If even one piece is missing — say, a service forgets to propagate the header to its downstream call — the chain breaks, and that segment of the journey becomes invisible again.

1. Detecting an incoming correlation ID

   When a request arrives at a service, the very first thing a well-built service does (usually inside a piece of code called middleware, interceptor or filter) is check: “Does this incoming request already carry a correlation ID header?” This matters because a request might be arriving from another internal service (which already generated and attached an ID upstream) or directly from an external client (which has no ID yet).

2. Generate if missing

   If no correlation ID is found, the service generates a brand-new one, typically a UUID version 4 (fully random). If one is found, the service simply reuses it, unchanged. This “generate-if-missing, else-reuse” rule is the single most important logic in the entire pattern.

3. Store it in thread-local / request-scoped context

   The service then stores this ID somewhere that the rest of the code, for the duration of handling this one request, can access without needing it passed explicitly as a function parameter. In Java, this is almost always done using SLF4J’s MDC (Mapped Diagnostic Context), which under the hood uses a ThreadLocal variable — a special kind of variable that has a separate, isolated copy for each thread. Since most traditional web servers handle one request per thread, this works naturally: each thread has its own private correlation ID visible only to code running on that thread.

4. Attach it to every outgoing call

   Whenever the current service needs to call another service — over HTTP, gRPC or by publishing a message — it must read the correlation ID from its context and attach it to the outgoing request’s headers or message metadata. This is usually automated using a shared HTTP client interceptor, so individual developers do not have to remember to do it manually on every single call.

5. Log with the ID automatically included

   Because the ID lives in the MDC, the logging framework’s configured output pattern can simply reference it (e.g., %X{correlationId} in Logback), and every log statement written during that request automatically includes it — without the developer writing log.info("orderId=" + id + " correlationId=" + correlationId …) by hand every time.

6. Clean up

   Once the request finishes (successfully or with an error), the service must clear the correlation ID from thread-local storage. This step is easy to forget, but it is critical: web servers commonly reuse threads from a pool for the next incoming request, and if the old correlation ID is not cleared, it could accidentally “leak” onto a completely unrelated future request’s logs, causing confusing, incorrect traces.

5.7 · A minimal Java example

Here is a simplified Spring Boot filter that implements exactly the steps above. In real production code, you would use a well-tested library rather than hand-rolling this, but seeing it written out makes the mechanism concrete.

@Component
public class CorrelationIdFilter extends OncePerRequestFilter {

    private static final String HEADER_NAME = "X-Correlation-ID";
    private static final String MDC_KEY = "correlationId";

    @Override
    protected void doFilterInternal(HttpServletRequest request,
                                     HttpServletResponse response,
                                     FilterChain chain)
            throws ServletException, IOException {

        // Step 1 & 2: reuse if present, otherwise generate a new one
        String correlationId = request.getHeader(HEADER_NAME);
        if (correlationId == null || correlationId.isBlank()) {
            correlationId = UUID.randomUUID().toString();
        }

        try {
            // Step 3: store in thread-local context
            MDC.put(MDC_KEY, correlationId);

            // Echo it back so the client can reference it in support tickets
            response.setHeader(HEADER_NAME, correlationId);

            chain.doFilter(request, response);
        } finally {
            // Step 6: always clean up, even if an exception occurred
            MDC.remove(MDC_KEY);
        }
    }
}

And a matching Logback pattern that automatically prints the ID on every line:

<pattern>%d{HH:mm:ss.SSS} [%thread] %-5level [correlationId=%X{correlationId}] %logger{36} - %msg%n</pattern>

With this in place, a developer writes ordinary code like log.info("Order created"), and the output automatically becomes something like:

14:02:11.045 [http-nio-8080-exec-3] INFO  [correlationId=7f3a9e21-4b6d-4c2a-9f11-8e2d5c7a10bb] c.u.OrderService - Order created

6.1 · Birth — creation at the edge

The API Gateway is usually the best place to generate the ID, because it is the single narrowest point through which all external traffic must pass. Generating it any later risks some requests slipping through without one; generating it earlier (on the client itself, such as a mobile app) is also a valid and increasingly common pattern, since it lets you trace a request even before it reaches your backend, including client-side retries and network failures.

6.2 · Growth — propagation across services

As the request fans out — Order Service calling Inventory Service and Payment Service, Payment Service calling an external Bank API — the same ID is attached to every single outgoing call. Even asynchronous side-effects, like publishing an event to a message queue for the Notification Service to consume later, must carry the ID forward inside the message.

6.3 · Branching — parallel calls

Notice that Order Service calls both Inventory Service and Payment Service. These can happen in parallel (at the same time) or sequentially. Either way, both calls carry the identical correlation ID — the ID does not fork into two different values just because the work forked into two parallel branches. This is what allows an engineer to later see the complete “tree” of everything that happened for one order, including parallel branches, all under one shared ID.

6.4 · Maturity — aggregation in central logs

Each service, independently and without knowing about the others, ships its logs to the central logging platform. Because every line is tagged with the same correlation ID, the platform can later group and sort all of them by timestamp, reconstructing the full timeline even though the individual services never directly communicated about logging.

6.5 · Death — expiry

The correlation ID’s “active life” ends when the original request is fully handled — the HTTP response is sent, or the background job completes. However, the log records containing it typically live on for much longer, according to the organisation’s log retention policy (commonly somewhere between 7 days and several years, depending on compliance requirements). The ID is never “reused” for a different request; a new request always gets a new ID.

7.1 · Advantages

7.2 · Disadvantages & limitations

7.3 · Trade-off: simplicity vs full distributed tracing

A basic correlation ID system is cheap and fast to build, and delivers huge debugging value almost immediately. Full distributed tracing (OpenTelemetry, Jaeger) delivers far richer information — exact timing of every hop, a visual waterfall diagram, error attribution to a specific span — but costs more to set up, run and store. Many teams start with a simple correlation ID and grow into full tracing as their system’s complexity increases.

8.1 · Generation cost

Generating a UUID version 4 is an extremely cheap operation — it typically takes well under a microsecond and requires no network call, no database lookup, and no coordination with any other server. This is a deliberate design choice: correlation IDs must never become a performance bottleneck, since they sit directly in the hot path of every single request.

8.2 · Header/metadata size

A standard UUID string is 36 characters. Attaching this to every HTTP header or message adds a small, fixed, predictable amount of overhead — typically negligible compared to the rest of a request’s payload, even at very high throughput (tens of thousands of requests per second).

8.3 · Log volume and indexing

The real scalability concern is not the ID itself, but what happens downstream: centralised log aggregation systems must index the correlation ID field efficiently so that searching by it remains fast even across billions of log lines. This is why teams typically configure the correlation ID as a dedicated, indexed field (rather than just free text buried inside a log message) in tools like Elasticsearch — turning what could be a slow full-text search into a fast, targeted lookup.

8.4 · Sampling at extreme scale

At companies operating at Netflix or Uber’s scale — billions of requests per day — storing full, detailed traces for every single request becomes prohibitively expensive in storage and processing cost. Many organisations apply sampling: they might trace and store detailed data for only 1% or 5% of requests (chosen randomly, or biased toward error cases), while still attaching a correlation ID to 100% of requests for basic log correlation. This gives cheap, universal debugging via correlation IDs, plus deep, detailed tracing on a representative sample.

8.5 · Asynchronous and batch workloads

In high-throughput streaming systems (like Kafka consumers processing millions of events per hour), correlation IDs are typically carried as message headers, so a downstream consumer can log with the same ID without needing to re-derive it. This keeps the propagation cost proportional to message count, not to processing complexity.

9.1 · The correlation ID system should never be a single point of failure

Because UUID generation happens locally on each machine with no external dependency, the correlation ID mechanism itself is inherently highly available — there is no central “ID server” that could go down and block the entire system. This is a deliberate and important architectural decision; some early distributed systems used centralised sequence generators for unique IDs, and those became bottlenecks and outage risks. UUIDs avoid this entirely.

9.2 · Failure scenarios and correlation IDs

Correlation IDs become especially valuable during partial failures — situations where some services are healthy and others are degraded or down, which is extremely common in distributed systems (this connects to the CAP theorem, discussed below). When only some services in a chain fail, correlation IDs let engineers quickly see exactly where in the chain the failure occurred, rather than needing to individually check every single service’s health.

9.3 · Retry storms and duplicate correlation IDs

A subtle reliability question: if a client retries a failed request, should the retry get the same correlation ID or a new one? Most teams choose to give retries a new correlation ID, but include the original ID as an additional field (sometimes called a “causation ID” or “parent request ID”). This way, engineers can see both “this was a retry” and “here is the original attempt it relates to,” without conflating them into one indistinguishable trail.

9.4 · Correlation IDs and circuit breakers

In resilience patterns like the Circuit Breaker (used to stop calling a failing downstream service repeatedly), correlation IDs help engineers understand exactly which requests were rejected by an open circuit breaker versus which ones actually reached the downstream service and failed there — a distinction that is otherwise very hard to see from logs alone.

9.5 · Disaster recovery considerations

When an organisation runs disaster recovery drills — deliberately simulating a data center failure and failing traffic over to a backup region — correlation IDs are essential for verifying that requests routed through the new region behave correctly end-to-end, and for comparing failure rates before and after the failover, request by request.

10.1 · Correlation IDs should be opaque, not meaningful

A correlation ID must never encode sensitive information directly — it should not be built from a customer’s email address, government ID number or account number. If it did, and that ID were ever exposed (for example, in a browser’s network tab, or an error page shown to the user), it could leak private data. A random UUID carries no such risk, because it is meaningless on its own.

10.2 · Trusting client-supplied correlation IDs

Some systems allow the client (a mobile app or browser) to generate the correlation ID and send it to the server. This is useful for tracing a request from the very first moment a user taps a button, even before it reaches your backend. However, it introduces a security consideration: a malicious client could send a deliberately crafted correlation ID designed to break log parsing, inject harmful characters, or attempt a log injection attack (where an attacker tries to forge fake log entries by embedding special characters like newlines into a field that gets logged).

10.3 · Correlation IDs and access control

Correlation IDs themselves do not grant any permission or access — they are not authentication tokens, and should never be treated as such. A common security mistake is confusing a correlation ID with a session token or API key. The two serve entirely different purposes: one identifies a request for tracing, the other proves who is making the request and what they are allowed to do.

10.4 · Exposing correlation IDs to end users

Many production systems intentionally show the correlation ID to the end user on error pages (for example, “Something went wrong. Reference: 7f3a9e21-…”) so the user can share it with customer support. This is safe, since the ID itself is meaningless without access to the internal, access-controlled logging system — but organisations must ensure their log storage itself remains properly access-controlled, since the logs behind that ID could contain sensitive request details.

10.5 · Data privacy and log retention

Because correlation IDs make it very easy to pull together everything about one user’s request, teams must be careful that this convenience does not violate data privacy regulations like GDPR or India’s Digital Personal Data Protection Act. If logs tied to a correlation ID contain personal data, that data is subject to the same retention limits, deletion rights and access controls as any other personal data the company stores.

11.1 · Structured logging

Correlation IDs work best alongside structured logging — writing logs as machine-readable objects (typically JSON) rather than plain sentences. A structured log line looks like this:

{
  "timestamp": "2026-07-17T09:14:22.104Z",
  "level": "INFO",
  "service": "payment-service",
  "correlationId": "7f3a9e21-4b6d-4c2a-9f11-8e2d5c7a10bb",
  "message": "Payment authorized",
  "amount": 1499,
  "currency": "INR"
}

Because the correlation ID is its own field (not buried in a free-text sentence), log platforms can filter, group and count by it with very high efficiency.

11.2 · The MDC pattern in practice

As shown earlier, Java’s MDC (Mapped Diagnostic Context) is the standard mechanism to make this automatic. Once set, every subsequent log.info(), log.warn() or log.error() call on that thread automatically includes the correlation ID, with zero extra effort from the developer writing business logic.

11.3 · Metrics and correlation IDs

Metrics (like “average response time” or “requests per second”) are usually aggregated numbers and do not carry a correlation ID themselves — that would create too much data to store efficiently. Instead, metrics answer “how is the system doing overall,” while correlation IDs answer “what exactly happened to this one request.” Good observability systems let you jump from an unusual metric spike (e.g., a sudden rise in error rate) directly into a sample of the correlation IDs that experienced errors during that spike, connecting the “what” (metrics) with the “why” (logs and traces).

11.4 · Distributed tracing dashboards

Tools like Jaeger and Zipkin take the correlation ID concept further by visualising the entire request as a “waterfall” diagram — a horizontal bar for each service showing exactly when it started and finished relative to the others. This makes it immediately obvious which service was the slowest link in the chain, something plain log searching cannot show as clearly.

11.5 · Alerting

Modern monitoring systems (Prometheus with Alertmanager, Datadog, New Relic) can trigger alerts based on error rate thresholds, and the resulting alert notification commonly includes a direct link, pre-filled with a sample correlation ID, so the on-call engineer can jump straight from “here is an alert” to “here is one real, concrete example of the failure,” cutting investigation time dramatically.

12.1 · Cloud load balancers and correlation IDs

Most cloud providers’ load balancers and API gateways can automatically inject a request ID if the client didn’t supply one — for example, AWS Application Load Balancer’s X-Amzn-Trace-Id, or a custom rule in an API Gateway service. Teams often choose to either use this cloud-provided ID directly as their correlation ID, or generate their own application-level ID and store the cloud-provided one as a secondary reference field.

12.2 · Kubernetes and service mesh

In Kubernetes environments using a service mesh like Istio or Linkerd, correlation and tracing headers can be automatically propagated at the network proxy layer (via the mesh’s sidecar containers), reducing the burden on individual application code to remember to forward headers manually. This is a major reason service meshes became popular in large microservices deployments — they solve cross-cutting concerns like this centrally, instead of requiring every team to reimplement it.

12.3 · Serverless / Functions-as-a-Service

In serverless platforms like AWS Lambda, Google Cloud Functions or Azure Functions, each invocation is typically short-lived and stateless. Correlation IDs are just as important here — often more so, since serverless architectures tend to chain many small functions together via event triggers. Cloud providers usually supply their own built-in invocation ID, but teams frequently layer a custom, business-level correlation ID on top so it can be tracked consistently even as a request crosses from a traditional service into a serverless function and back.

12.4 · Multi-region and multi-cloud deployments

When a system spans multiple geographic regions or multiple cloud providers (for latency, redundancy or regulatory reasons), correlation IDs become the only reliable way to trace a request that might start in one region and, due to failover or routing logic, complete in another — since each region likely has its own separate log storage.

12.5 · CI/CD and testing

Correlation IDs are also valuable in automated testing pipelines. Integration tests can generate a known correlation ID before making a request, then query the logging system afterward to assert that specific expected log lines were produced — turning “did the system behave correctly internally” into something a test can automatically verify, not just “did the response look right.”

13.1 · Standard header names

While there is no single universally mandated header name, a few conventions are extremely common across the industry:

13.2 · REST APIs

In REST-based microservices, the correlation ID is almost always passed as an HTTP header (never as a URL query parameter or a body field, since headers are the conventional, cross-cutting place for metadata that isn’t part of the actual business payload).

13.3 · gRPC

gRPC, a high-performance binary RPC framework popular in microservices, uses “metadata” (conceptually similar to HTTP headers) to carry a correlation ID between a gRPC client and server, typically injected via a client-side and server-side interceptor.

13.4 · GraphQL

Since GraphQL APIs typically communicate over a single HTTP endpoint, the correlation ID is still passed as a normal HTTP header on the GraphQL request, exactly as with REST — GraphQL’s query language itself is unrelated to how correlation IDs are transported.

13.5 · Message queues (Kafka, RabbitMQ, SQS)

In event-driven microservices, when Service A publishes an event that Service B later consumes asynchronously (possibly seconds, minutes or hours later), the correlation ID must be embedded in the message itself — for example, as a Kafka message header, or a field inside the message payload — since there is no live HTTP connection to carry a header across in real time.

ProducerRecord<String, String> record =
    new ProducerRecord<>("order-events", orderId, orderEventJson);

record.headers().add("correlationId",
    MDC.get("correlationId").getBytes(StandardCharsets.UTF_8));

kafkaProducer.send(record);

@KafkaListener(topics = "order-events")
public void consume(ConsumerRecord<String, String> record) {
    Header header = record.headers().lastHeader("correlationId");
    String correlationId = header != null
        ? new String(header.value(), StandardCharsets.UTF_8)
        : UUID.randomUUID().toString();

    try {
        MDC.put("correlationId", correlationId);
        log.info("Processing order event");
        // ... business logic ...
    } finally {
        MDC.remove("correlationId");
    }
}

13.6 · API gateways as the natural entry point

In a microservices architecture, the API Gateway (tools like Kong, Amazon API Gateway or a custom Spring Cloud Gateway) is the ideal, centralised place to enforce “every request must have a correlation ID by the time it leaves this gateway,” since it is the one component every external request must pass through, removing the need to trust every individual downstream team to implement this correctly themselves.

14.1 · Good patterns

14.2 · Anti-patterns (common mistakes to avoid)

15.1 · Best practices

• Generate at the earliest possible entry point — ideally the client app or the API Gateway.
• Use a standard, well-tested UUID library rather than writing custom random-string generation.
• Adopt a consistent header name across your whole organisation, and document it clearly; consider adopting the W3C traceparent standard for interoperability.
• Automate propagation through shared libraries, interceptors and service mesh sidecars — never rely on individual developers remembering to do it manually every time.
• Always clean up thread-local context in a finally block, guaranteeing cleanup even when exceptions occur.
• Validate externally supplied IDs before logging or storing them.
• Return the correlation ID to the client, especially in error responses, so users can reference it when contacting support.
• Index the correlation ID field in your log storage system for fast searching.
• Extend context propagation carefully into asynchronous, reactive and thread-pool-based code paths, testing this explicitly.
• Treat correlation IDs as the foundation for growing into full distributed tracing as your system scales.

15.2 · Common mistakes

• Forgetting to propagate the ID into asynchronous message queue calls.
• Logging the correlation ID as unstructured free text instead of a dedicated, indexed field.
• Using a short, non-random or predictable ID format that risks collisions.
• Not returning the correlation ID in error responses, making customer support investigations harder.
• Assuming a service mesh automatically handles everything, without verifying application code correctly reads and reuses the propagated context.
• Mixing up correlation IDs with authentication tokens or session identifiers.
• Not setting log retention policies appropriately, either losing useful trace history too early or retaining sensitive data too long.

16.1 · Netflix

Netflix operates one of the largest microservices architectures in the world, with hundreds of independently deployed services handling video streaming, recommendations, billing and device management for hundreds of millions of subscribers. Netflix’s public engineering writing has long emphasised that request-level tracing (correlation IDs and their evolution into full distributed tracing) is essential infrastructure, not an optional add-on, given the sheer number of services a single “play” action can touch.

16.2 · Amazon

Amazon’s internal engineering culture, and its AWS X-Ray tracing product offered to customers, are both built around the same core idea: attach an identifier to a request at the edge, and propagate it through every downstream AWS service call (Lambda, API Gateway, DynamoDB, SQS), so engineers can visualise a request’s complete journey through a serverless or microservices-based application.

16.3 · Uber

Uber, coordinating rides, deliveries and payments across a vast number of backend services in real time, has published extensively about building and operating Jaeger, an open-source distributed tracing system they created and later donated to the Cloud Native Computing Foundation (CNCF). Jaeger’s core data model is built directly on the trace ID / span ID pattern that generalises the correlation ID concept.

16.4 · Google

Google’s internal Dapper paper, published in 2010, is widely credited as one of the most influential documents in the history of distributed tracing. It described how Google engineers needed a way to trace requests across its massive internal service architecture, directly inspiring later open-source systems like Zipkin (built at Twitter, influenced by Dapper) and, eventually, the OpenTelemetry standard used broadly across the industry today.

16.5 · Everyday example: food delivery apps

When you order food through a delivery app, one tap on “Place Order” typically triggers calls to a restaurant service, a payment service, a delivery-partner matching service, a maps/routing service and a notifications service — all tied together, behind the scenes, by one correlation ID, so that if your order goes wrong, support engineers can reconstruct exactly what happened across every one of those systems.

A correlation ID is a small idea with an outsized impact on how effectively engineers can operate distributed systems. As applications grew from single monolithic programs into networks of dozens or hundreds of independently deployed microservices, the ability to answer “what happened to this one request?” stopped being free, and had to be deliberately engineered.

• A correlation ID is a unique, opaque identifier generated once per request and propagated, unchanged, through every service, log line and message involved in handling that request.
• It is almost always implemented as a UUID, carried via an HTTP header (like X-Correlation-ID or the standardised traceparent), stored in thread-local context (MDC in Java), and automatically stamped onto every log line.
• The core discipline required is simple but strict: generate only if missing, always propagate what’s received, always clean up after the request completes, and never let one service silently overwrite an existing ID.
• Correlation IDs form the foundation for more advanced observability tools — distributed tracing systems like Jaeger, Zipkin and OpenTelemetry are a richer, standardised evolution of the exact same underlying idea.
• They are cheap to implement, essentially free in performance cost, and deliver enormous value in reducing debugging time and improving incident response, especially at organisations like Netflix, Amazon, Uber and Google, which operate hundreds of interdependent services.
• Getting this right requires treating propagation as an automated, framework-level responsibility — not something left to individual developer memory — and paying careful attention to edge cases like asynchronous code, message queues, retries and security validation of externally supplied values.