Distributed Trace Growth Calculator

Project how distributed trace volume will grow as microservices and traffic increase.

About Distributed Trace Growth Calculator

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

Worked example

With the default values below, Distributed Trace Growth Calculator returns Month-over-Month Growth of 23.6%. Change any input above and every figure here is recalculated in your browser.

Inputs used

Current Servicesaccepts 0–100,000 services: 40 services
New Services per Monthaccepts 0–10,000 services/month: 3 services/month
Traces per Service per Dayaccepts 0–1,000,000,000 traces/day: 500,000 traces/day
Avg Spans per Traceaccepts 1–10,000 spans: 10 spans
Cardinality Factoraccepts 1–5 ×: 1.15 ×

Results

Month-over-Month Growth: 23.6%
Projected Spans/Day Next Month: 247,250,000 spans/day
Current Spans/Day: 200,000,000 spans/day
Projected Spans/Day in 12 Months: 2,033,095,040 spans/day
Projected Service Count in 12 Months: 76 services

Step by step

1Current spans/day: services × traces/service × spans/trace= 200,000,000 spans/day
2Next month spans/day (with cardinality growth)= 247,250,000 spans/day
3Growth this month= 23.6%

Assumptions and limits

The result is derived only from the 5 inputs listed above. Anything not among them is not part of the calculation.
In particular, this calculator does not take inflation, tax, fees or charges or compounding frequency into account.
Figures are rounded for display to 1 decimal place, so totals built from several rounded parts can differ slightly from the unrounded arithmetic.

How these calculators are built and tested is described on the Methodology page. If a figure looks wrong, please report it.

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.