Distributed Trace Growth Calculator
Project distributed tracing data growth per month as new services are added, accounting for span cardinality per service.
Inputs
Number of services currently instrumented for tracing.
Expected rate of new services being onboarded to tracing.
Average traces touching one service per day.
Average spans generated per trace across the call graph.
Multiplier capturing how each new service increases inter-service call fan-out (more services → more cross-service spans per trace).
Month-over-Month Growth
23.6%
Projected Spans/Day Next Month
247,250,000spans/day
Current Spans/Day
200,000,000spans/day
Projected Spans/Day in 12 Months
2,033,095,040spans/day
Projected Service Count in 12 Months
76services
Step by step
Current spans/day: services × traces/service × spans/trace
40 × 500,000 × 10
= 200,000,000 spans/day
Next month spans/day (with cardinality growth)
43 × 500,000 × 10 × 1.15
= 247,250,000 spans/day
Growth this month
247,250,000 − 200,000,000
= 23.6%
How it works
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.
Formula
projected_traces_per_sec = current_traces_per_sec + growth_per_month × projection_months
- current_traces_per_sec
- Current trace ingestion rate
- growth_per_month
- Monthly increase in traces per second
- projection_months
- Months to project forward
Frequently Asked Questions
Why does adding services increase span cardinality faster than linearly?
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.
What's a realistic cardinality factor?
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.
How should this inform sampling strategy?
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.
Does this model apply to metrics cardinality too?
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.
You might also need
- Zipkin Storage CalculatorCommonly used together
- Tracing Storage CalculatorCommonly used together
- Jaeger Capacity CalculatorCommonly used together
- Log Ingestion CalculatorAlso in Logging & Observability
- OpenTelemetry Data Volume CalculatorAlso in Logging & Observability
- Fluentd Buffer CalculatorAlso in Logging & Observability