Distributed traces track how a system processes a single request — not what customers do over time. Confusing traces with business logic leads to poorly instrumented systems. A trace captures the execution path of one request (milliseconds to seconds), while business data like order history or transaction records lives in your application database and spans days or weeks. Adding business identifiers like `order_id` as span attributes is valuable as a debugging correlation key — it lets you find all traces touching a specific order — but it won't reconstruct a full business workflow. Traces are also sampled and have short retention windows, making them unsuitable as durable business records. The right approach: use traces to understand infrastructure behavior per request, and use your database or event log for domain-level continuity.
Table of contents
What Business Logic Looks LikeWhat a Trace Actually IsThe Structural DifferenceDoes Custom Instrumentation with order_id Help?The Right Tool for Each JobThe TakeawaySort: