Distributed traces track how your system processed a single request — not what your customers did over time. Confusing the two leads to poorly instrumented systems.

Last9 is a  blog focusing on DevOps practices, cloud architecture, and software engineering methodologies. Through insightful articles, tutorials, and case studies, Last9 addresses various aspects of modern software development, including continuous integration and continuous delivery (CI/CD), infrastructure as code (IaC), containerization, and microservices architecture. By sharing best practices, real-world experiences, and expert insights, Last9 equips developers, DevOps engineers, and IT professionals with the knowledge and tools needed to build, deploy, and manage resilient and scalable cloud-native applications.

Last9

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.

Traces Are Not Your Business Logic

Does Custom Instrumentation with order_id Help?