Traffic Split Calculator

Calculate request distribution across service versions given traffic split weights.

About Traffic Split Calculator

Weighted traffic splitting distributes total request volume across service versions proportionally to their configured weights: per_version_rps = total_rps × weight ÷ sum(weights). This is the underlying mechanism behind canary releases, blue-green cutovers and A/B tests in a service mesh — weights don't need to sum to 100, since the router normalizes them, but expressing them as percentages that sum to 100 is the common convention (e.g. Istio VirtualService weight fields).

Formulas

Traffic per version

rps_version = total_rps × weight_percent / 100

total_rps: Total incoming requests per second
weight_percent: Traffic weight assigned to this version (%)

Canary error rate impact

user_facing_error_rate = canary_error_rate × canary_weight / 100

canary_error_rate: Error rate of the canary version
canary_weight: Traffic percentage routed to canary

Worked example

With the default values below, Traffic Split Calculator returns Largest Split (RPS) of 8,000.0. Change any input above and every figure here is recalculated in your browser.

Inputs used

Total Request Rateaccepts 0–100,000,000 requests/sec: 10,000 requests/sec
Version Weights: 80, 20
Version Labels: stable, canary

Results

Largest Split (RPS): 8,000.0 requests/sec
Largest Split Version: stable
Remaining Traffic (RPS): 2,000.0 requests/sec
Sum of Weights: 100

Step by step

1Sum of weights= 100
2stable share= 8000.0 req/sec (80.0%)
3canary share= 2000.0 req/sec (20.0%)

Assumptions and limits

The result is derived only from the 3 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

Do traffic split weights have to add up to 100?

No — most service mesh implementations (Istio, Linkerd, various API gateways) normalize whatever weights you provide, so '4, 1' produces the same 80/20 split as '80, 20'. Using percentages that sum to 100 is just a readability convention.

How is this different from a canary deployment rollout?

A canary deployment progressively increases one version's traffic weight over time through several discrete stages; a traffic split is the mechanism used at each stage — this calculator models a single point-in-time split, while the canary deployment calculator models the full staged timeline.

Can I use this for more than two versions?

Yes — provide as many comma-separated weights (and optional labels) as you have versions; the calculator normalizes and splits traffic across all of them, which is useful for multi-variant A/B/n testing.

Does request-level weighting guarantee exact traffic percentages?

Over a large enough sample, yes, assuming random/weighted-random routing; for small request volumes or session-affinity-based routing (sticky sessions), actual observed splits can deviate from configured weights until volume is statistically significant.