Business Correlation Identifier

Distributed tracing answers "why was this request slow". In a domain where an operation spans days, crosses organisational boundaries and involves batch jobs and third-party callbacks, that is not the question anyone asks.

The question is "what happened to this shipment", and answering it requires a business identifier present on every signal — not a trace ID that expires when the request ends.

Why it matters

It is the primary tool of support, operations and dispute resolution, and it is the difference between an investigation taking minutes and taking a day. It is also the only way to reconstruct an operation whose lifecycle exceeds any single trace.

Teams that build only distributed tracing find it does not serve the people who need observability most, and teams that build only business correlation cannot diagnose latency.

Implementation patterns

• Assign the identifier at the origin of the business operation and carry it as a first-class field on every log, metric exemplar, event, job and outbound call.
• Propagate it explicitly across asynchronous boundaries. Message headers, job payloads, third-party request references — each is a manual instrumentation point, and each one missed leaves a gap in the history.
• Include it in outbound calls to external parties, so their record and yours can be joined when reconciling.
• Index it, deliberately, since this is the one field that must be searchable across all signal types even when most others are not.
• Pair it with distributed tracing rather than replacing it. Trace context uses links rather than parent-child relationships across queues — modelling a queued consumer as a child produces traces that appear to last hours — while the business identifier stitches the whole lifecycle together.
• Expose it to the customer. A tracking number that is also the internal correlation key removes an entire translation step from every support interaction.

Industry example

Logistics platforms such as Delhivery, Porter and Shiprocket coordinate operations that last days across warehouses, carriers, drivers and customer systems. The trace of any single request is nearly useless; the event history of the shipment is the product's operational core, and it is what an operations team, a customer and a carrier dispute all need.

The same shape governs insurance claims, payment settlement, employment onboarding, and any workflow whose lifecycle exceeds a request.

Failure scenarios

• Only distributed tracing, which cannot answer the question the business asks.
• The identifier lost at an asynchronous boundary, so the history has holes exactly where the problem was.
• Different identifiers in different systems, requiring a join through a mapping table that is itself incomplete.
• The identifier not indexed, so the search that matters is the slow one.
• No external reference embedded, making reconciliation with a third party manual.

Trade-offs

Carrying and indexing a business identifier on every signal costs storage and index size, and it is exactly the high-cardinality dimension that cardinality budgets exist to restrain.

The resolution is that it belongs on logs and traces, where high cardinality is native, and not on metrics. That gives searchability without multiplying series count — and it is the reason the signal separation matters rather than being a taxonomy exercise.

Interview question

"A customer says their package has been stuck for two days. Tell me exactly what you would search for, in what system, and what would have to be true of your instrumentation for that search to return the whole story."