Project how distributed trace volume will grow as microservices and traffic increase.
Distributed trace volume grows faster than service count alone because each new service adds not just its own spans but additional cross-service call edges — a cardinality factor captures this compounding effect: growth_per_month = new_services × traces_per_service × spans_per_trace × cardinality_factor. Applying the same cardinality factor compounded over 12 months illustrates why tracing costs can grow much faster than headcount or service count in a microservices architecture.
projected_traces_per_sec = current_traces_per_sec + growth_per_month × projection_months
In a densely interconnected microservices architecture, adding one service typically adds calls both to and from several existing services, so the number of unique service-to-service call paths (and their span cardinality) grows faster than the service count itself.
For loosely coupled services with few dependencies, a factor close to 1.0-1.1 (near-linear growth) is realistic; for highly interconnected service meshes, 1.2-1.5 compounding per month during rapid service growth phases is not unusual.
If projected growth threatens to outpace storage budget, proactively lowering the sampling rate (rather than reactively cutting retention later) preserves trace visibility breadth across more services while controlling absolute volume.
The same compounding principle applies to metrics — each new service can add new label dimensions and series combinations, so teams tracking metrics cardinality growth often see similar superlinear trends as service count increases.