Calculate request distribution across service versions given traffic split weights.
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).
Traffic per version
rps_version = total_rps × weight_percent / 100
Canary error rate impact
user_facing_error_rate = canary_error_rate × canary_weight / 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.
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.
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.
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.