ShapleyIQ: Influence Quantification by Shapley Values for Performance Debugging of Microservices

A big online service is built from thousands of small services calling each other, and when the whole thing gets slow it is genuinely hard to say which component is to blame, because a slow component might just be waiting on another one or running in parallel where it does not matter; this work from Alibaba brings in Shapley values, a fair-credit idea from game theory, to score how much each component actually caused the end-to-end slowdown, adds a causal-splitting rule so a component is not blamed for delay it merely inherited, and a decomposition trick that turns the normally exponential Shapley computation into a fast one, running it in production for a year and cutting failures by 83 percent.

The argument in one glance

Problem

When a microservice system slows down, which part is to blame?

A cloud application is thousands of small services calling one another, with constant, unavoidable anomalies. Just detecting that a component looks abnormal is not enough — you need to quantify how much each one actually influences the end-to-end performance a user sees, on a causal graph with subtle timing where a slow-looking part may be blameless.
What people did

Flag the anomalous components and call them root causes

Detect components whose metrics deviate from normal, or trace correlations through the dependency graph, and report the anomalous ones as the likely culprits.
Why it fell short

Similar anomalies can have opposite implications

A component running in parallel with a slower sibling, or merely waiting on a downstream call, looks abnormal but is not the cause. Fixing it does nothing. Two anomalies identical on the surface may demand opposite actions, and a tiny code change can flip whether a component is a root cause, so anomaly-flagging misattributes blame.
This paper's idea

Fairly quantify each component's influence with Shapley values (ShapleyIQ)

ShapleyIQ scores how much each component actually caused the end-to-end slowdown using Shapley values, a fair-credit concept from game theory, computed against counterfactuals from physical models. A causal-splitting rule stops a component being blamed for delay it merely inherited, and a decomposition property turns the normally exponential Shapley computation fast. Deployed at Alibaba for a year, it cut failures by 83 percent.

Why this problem is worth solving

Microservice architectures are how large online systems are built, and they trade one kind of fragility for another.

A microservice system decomposes a big application into thousands of small, independently-running services that call one another over the network — one service handles authentication, another a database query, another a recommendation. This design is deliberately built on the assumption that individual components will fault, so the system keeps working even as parts misbehave, which makes it robust but also means anomalies are constant and unavoidable. That is exactly what makes operating such systems hard. At any moment, many components show metrics that deviate from their normal values, so simply detecting an anomaly tells you almost nothing — most are harmless operational variation. The question operators actually need answered is quantitative: when the end-to-end performance a user experiences, such as response time, gets worse, how much did each component’s variation actually contribute to that change? Only with an influence score can you tell the harmless deviations apart from the few components whose problems are genuinely driving the degradation and demand action.

Answering that question is subtle because the components are wired together with timing relationships that hide the true cause.

The components form a causal dependency graph, and delays propagate through it in ways that make a slow-looking component frequently blameless. Consider a service A that calls B and C in parallel and then does more work, where C in turn calls a component D. When everything’s time doubles, intuition might blame all the slow components, but the truth is subtler. Fixing C does nothing, because C’s delay is entirely inherited from waiting on D — C itself adds nothing. Fixing B does nothing either, because A waits for whichever of B and C is slower, and C dominates, so B’s time is masked by a threshold effect and never matters until it exceeds C. Only A and D turn out to be the real root causes: the delay the user sees returns to normal only when both are fixed. More strikingly, a tiny change to the code — moving a piece of A’s work to run earlier, in parallel with B and C instead of after them — flips A from being a root cause to not being one at all. So two anomalies that look identical on the surface can have completely opposite implications, and a purely anomaly-based or correlation-based diagnosis will confidently blame the wrong components. What is needed is a principled way to quantify each component’s true causal influence on the end-to-end metric.

What people did before, and where it broke

Detect anomalies and report the deviating components. Monitor each component’s metrics and flag those that depart from normal as suspects. Where it broke. In a system where anomalies are constant, most deviations are harmless, and a deviating component is often merely waiting on the real culprit, so this misattributes blame.
Correlate anomalies across the dependency graph. Trace which anomalies co-occur along the service call graph and rank components by correlation. Where it broke. Correlation is not causation, and timing effects like parallel execution and waiting mean a strongly-correlated component may contribute nothing, as with a component running in parallel with a slower sibling.
Predict counterfactuals with data-driven machine learning. Learn a model that predicts how metrics would change if components changed, from historical data alone. Where it broke. Such models predict forward effects but do not fairly allocate the observed end-to-end change back to individual causes, and they can miss the physical timing structure that determines which component actually matters.
Use standard Shapley values off the shelf. Apply the game-theory credit-allocation formula directly to score each component’s contribution. Where it broke. Standard Shapley values are symmetric, so a component whose delay is entirely caused by a downstream one gets equal credit with it, wrongly named a root cause; and the formula costs exponential time in the number of components, impractical at scale.
The gap. No method both respected the causal timing structure (so blame lands on true causes, not inherited delay) and computed influence efficiently enough for a live production system. Providing both is what ShapleyIQ does.

How ShapleyIQ works

From flagging anomalies to fairly quantified causal influence

↓ →
new
↓ →
new
↓ →
new
↓ →
new
↓ →
new

The idea

Score influence, do not just flag anomalies. ShapleyIQ reframes microservice diagnosis from detecting what looks abnormal to quantifying how much each component actually caused the end-to-end change a user feels. Its tool for this is the Shapley value, a concept from game theory for fairly dividing the credit for a joint outcome among the players who produced it: a component’s influence is its average marginal effect on the end-to-end metric, taken over all the ways it could be added to subsets of the other components. This gives a principled, comparable score rather than a binary abnormal-or-not label. Attributing an end-to-end performance problem to the components truly responsible, rather than reporting everything that happens to look wrong, is the same goal the trace-based root-cause-analysis work covered elsewhere on this site pursues, turning a flood of correlated symptoms across a microservice call graph into a focused verdict about where the fault actually originates.

Respect causality by splitting inherited delay from originated delay. Standard Shapley values have a fatal flaw here: because they are symmetric, a component whose slowdown is entirely inherited from a downstream call receives the same blame as the downstream cause itself, which is wrong. ShapleyIQ fixes this by splitting each factor into two parts — the portion of its delay caused by other components, and the remaining portion it originates on its own — and crediting only the originated part, a correction the paper calls splitting invariance that makes the scores match the true root causes. Carefully separating what a component genuinely caused from what merely flowed into it through the dependency structure is the same discipline the causal-ordering work covered elsewhere on this site is built on, reasoning precisely about which events truly precede and cause which others rather than being misled by things that merely co-occur or follow along.

Make the fair score cheap enough to run live. The Shapley value is famously expensive: computed directly, it sums over every subset of components, an exponential cost that is hopeless for a system with thousands of them. ShapleyIQ shows that the same splitting structure yields a decomposition property, letting it compute the influence in roughly n-log-n time in the number of factors involved in a specific issue — not the whole graph — which is the difference between a theoretical idea and a service that runs continuously in production. Exploiting a problem’s structure to collapse a combinatorially explosive computation into an efficient one, so a principled method becomes practical at real scale, is the same move the efficient-microservice-management work covered elsewhere on this site makes, turning an approach that would be prohibitively costly if done naively into one that meets the tight time and resource budgets of a live datacenter.

Following a diagnosis through ShapleyIQ

Diagnosing an end-to-end slowdown in a microservice system

A trace of ShapleyIQ attributing a response-time regression, following the paper's counterfactual and Shapley design.

Step 1 of 5

An end-to-end metric goes abnormal

Monitoring detects that a user-facing metric — say response time — has degraded from its normal value, triggering diagnosis. Many components on the call graph show deviations at the same time.

Anomalies are constant, so the deviating set is large and noisy.

Why it works

Influence scores separate harmless deviation from real cause. Because anomalies are constant in a microservice system → a quantitative influence score ranks components by actual contribution rather than mere deviation → so operators act on the few components truly driving the degradation.
Physical counterfactuals capture timing truth. Because delays combine by real rules — additive along a chain, maximum across parallel calls, thresholds when one path masks another → first-principle models compute what each subset of anomalies would actually do → so a masked or parallel component is correctly seen to contribute nothing.
Shapley values allocate credit fairly. Because the end-to-end change is a joint outcome of many components → averaging each component’s marginal effect over all subsets fairly divides the responsibility → so no single component is over- or under-credited by an arbitrary ordering.
Causal splitting fixes the symmetry flaw. Because standard Shapley symmetry blames an inheriting component equally with its cause → splitting each factor into inherited and originated parts credits only what a component originates → so a component merely waiting downstream is not misnamed a root cause.
Decomposition beats the exponential cost. Because generic Shapley values sum over exponentially many subsets → the splitting structure decomposes the computation into roughly n-log-n work → so the fair score is cheap enough to run continuously in production.

What it costs (trade-offs and scope)

It relies on first-principle physical models. ShapleyIQ evaluates counterfactuals with queueing and timing models rather than pure machine learning. This gives interpretable, physically-grounded results, but it requires that the system’s behavior be well captured by such models; workloads that badly violate the modeling assumptions would weaken the counterfactuals.
It needs a usable causal graph. The method takes the observed dependency graph as the causal structure. Extracting accurate causal graphs is known to be hard, and the paper uses a non-strict graph of possible relationships; errors or omissions in that graph propagate into the attribution.
The efficiency depends on the issue being local. The roughly n-log-n cost is in the number of factors of a specific issue under investigation, not the whole system graph. This is what makes it practical, but an issue implicating a very large, tightly-coupled set of factors would be more expensive.
Incomplete traces need extra handling. Real production tracing data is often incomplete, and the paper adds engineering optimizations to cope. The quality of attribution still depends on how much trace information is available for the issue.
Accuracy figures are for specific systems. The 97.3 percent top-1 accuracy is on Alibaba DBaaS data and 98.7 percent on the open-source TrainTicket benchmark; other systems, fault types, or tracing setups could shift the numbers, though the multi-root-cause advantage over baselines is large.
Root cause is defined via influence, not proven. The paper deliberately defines root causes through influence quantification rather than a universal notion of causation, so results are as meaningful as that operational definition and the underlying counterfactual model are for a given system.

The evaluation

Ways to diagnose an end-to-end microservice slowdown

Property	Anomaly or correlation ranking	Standard Shapley values	ShapleyIQ
What it reports
Handles inherited or masked delay
Basis of the score	Deviation or correlation	Counterfactuals, no causality	Physical-model counterfactuals plus causality
Computation cost
Top-1 root-cause accuracy		Not deployable

Ways to diagnose an end-to-end microservice slowdown, as compared in the paper. Anomaly detection or correlation ranking reports components that merely look abnormal, so it blames components that are only waiting on a downstream call or running in parallel with a slower sibling. Applying standard Shapley values gives a fair influence score but its symmetry property wrongly gives a component whose delay is entirely inherited the same credit as its cause, and it costs exponential time in the number of components. ShapleyIQ evaluates counterfactuals with first-principle physical models (such as queueing models capturing additive, parallel-maximum, and threshold timing effects), allocates influence with Shapley values, and adds a splitting-invariance property that divides each factor into inherited and originated parts so only true causes are credited, plus a decomposition property that computes the score in roughly n-log-n time in the number of factors of the issue. Deployed on Alibaba Cloud's DBaaS core infrastructure for over a year (15,629 operations, 86 services, 2,546 machines), it reduced system failures by 83.3 percent, and offline it reached 97.3 percent top-1 root-cause accuracy on production data (outperforming baselines by at least 28.7 percent) and 98.7 percent on TrainTicket; with multiple coexisting root causes it reached 98.6 percent where the best baseline reached only 34.0 percent.Underlined values explain themselves when clicked.

Where this stops working

What to keep in mind

ShapleyIQ is an unusually complete piece of systems work: a rigorous theoretical idea, carried through to a service deployed in production for over a year. The problem is real and underappreciated — in a microservice system built to tolerate constant component faults, detecting anomalies is nearly worthless, because most deviations are harmless and the ones that matter are hidden by timing. The paper’s central insight is to reframe diagnosis as influence quantification: rather than ask what looks abnormal, ask how much each component actually caused the end-to-end change a user experiences, and answer it with Shapley values, the game-theory notion of fairly dividing credit for a joint outcome. Two refinements make the idea work in practice. First, standard Shapley values are causally naive — their symmetry blames a component for delay it merely inherited from downstream — so ShapleyIQ splits each factor into inherited and originated parts and credits only what a component originates, which is what makes its scores match the true root causes in the tricky examples where a slow component is actually blameless. Second, Shapley values normally cost exponential time, so the same splitting structure is exploited as a decomposition property to compute the answer in roughly n-log-n time in the factors of a given issue, making it fast enough to run online. The evaluation is strong: an 83.3 percent reduction in failures on Alibaba’s DBaaS infrastructure, 97.3 percent top-1 accuracy on production data, and a striking advantage when multiple root causes coexist, where it reached 98.6 percent against a best baseline of 34.0 percent. Read the scope with care. The counterfactuals come from first-principle physical models like queueing, so the results are only as good as those models fit the system; the method needs a usable causal dependency graph, which is itself hard to extract accurately; the efficiency assumes the issue involves a manageable number of factors, not the whole graph; production traces are often incomplete and need extra engineering; and root cause is defined operationally through influence rather than proven in an absolute sense. The durable idea is that fair-credit allocation from game theory, combined with genuine causal structure and physical timing models, turns the noisy problem of microservice diagnosis into a quantitative, principled, and deployable one.

Background

Why microservice diagnosis keeps demanding better attribution

It helps to see ShapleyIQ within the broader struggle to operate large microservice systems, where the very design that makes them resilient — many independent components, built to tolerate faults — also makes them opaque, because a user-facing problem can originate anywhere in a deep, dynamic call graph and be masked by the timing relationships between components. As these systems have grown, operators have moved from staring at per-component dashboards toward tools that reason about the system as a whole and attribute end-to-end symptoms to their true sources. The end-to-end cloud-service cloning work covered elsewhere on this site reflects the same pressure from another angle, capturing the complex behavior of a networked cloud application faithfully enough to study and reproduce it, because understanding these systems requires treating their emergent, cross-component behavior as the object of study rather than any single service. The common thread is that in a world of thousands of interacting services, the scarce and valuable thing is a principled account of cause and effect across the whole graph — who is really responsible for what the user sees. ShapleyIQ’s contribution, quantifying influence with fair-credit game theory grounded in causal and physical structure, is one strong answer, and as microservice systems keep growing, the demand for attribution methods that are both rigorous and cheap enough to run live is only likely to intensify.

If you remember only three things

1. Modern cloud applications are microservice systems: thousands of small services calling one another, deliberately built to keep working as individual parts fault, so anomalies are constant and simply detecting an abnormal component is nearly useless. The real question is quantitative — how much does each component's variation actually influence the end-to-end performance a user sees, like response time. This is hard because components form a causal dependency graph with subtle timing: a slow-looking component may be blameless if it runs in parallel with a slower sibling (masked by a maximum) or merely waits on a downstream call (inherited delay). In the paper's example, when all times double, only two of four components are true root causes, and moving one piece of work to run earlier flips whether a component is a cause at all — so anomalies identical on the surface can demand opposite responses, and anomaly- or correlation-based diagnosis misattributes blame.
2. ShapleyIQ reframes diagnosis as influence quantification using Shapley values, a game-theory method for fairly dividing credit for a joint outcome: a component's influence is its average marginal effect on the end-to-end metric across all subsets of the other components. It evaluates the needed counterfactuals (what the metric would be if a set of components were abnormal) with first-principle physical models such as queueing, capturing additive, parallel-maximum, and threshold timing effects, rather than pure machine learning. Two refinements make it work: a splitting-invariance property divides each factor into the part caused by other components and its own originated part, crediting only the latter so a component is not blamed for inherited delay (fixing standard Shapley's symmetry flaw that would wrongly blame a merely-waiting component); and a decomposition property collapses the normally exponential Shapley computation into roughly n-log-n time in the number of factors of the specific issue, making it fast enough to run online.
3. Deployed on Alibaba Cloud's DBaaS core infrastructure for over a year (15,629 operations, 86 services, 2,546 machines), ShapleyIQ reduced system failures by 83.3 percent and improved operations efficiency. Offline it achieved 97.3 percent top-1 root-cause accuracy on production data (beating baselines by at least 28.7 percent absolute) and 98.7 percent on the open-source TrainTicket benchmark; when multiple root causes coexist it reached 98.6 percent where the best baseline managed only 34.0 percent. Scope: the counterfactuals depend on physical models fitting the system, it needs a usable (hard-to-extract) causal graph, its efficiency assumes an issue involves a manageable number of factors, incomplete production traces need extra handling, and root cause is defined operationally through influence rather than proven absolutely. The durable lesson is that fair-credit allocation from game theory, grounded in real causal structure and physical timing, turns noisy microservice diagnosis into a principled, quantitative, deployable task.

Check yourself

Check your understanding

1. Why is simply detecting anomalous components not enough to diagnose a microservice slowdown?
2. What are Shapley values, and how does ShapleyIQ use them?
3. What are the two key refinements ShapleyIQ adds to standard Shapley values?
4. What did ShapleyIQ achieve in deployment and evaluation, and what are its limits?

Sources

The paper is “ShapleyIQ: Influence Quantification by Shapley Values for Performance Debugging of Microservices” by Ye Li, Jian Tan, Bin Wu, Xiao He, and Feifei Li, published at ASPLOS 2023, DOI 10.1145/3623278.3624771. All authors are at Alibaba Group.

This explainer is based on the full text of the paper, obtained from the published version (retrieved via the Internet Archive’s Wayback Machine). The problem framing (microservice systems built to tolerate constant component faults, why anomaly detection alone is uninformative, the causal dependency graph with subtle timing, and the motivating example where A calls B and C in parallel and C calls D twice, so that when all times double only A and D are true root causes while C is inherited and B is masked, and moving A’s work earlier flips whether A is a cause), the ShapleyIQ design (reframing diagnosis as influence quantification; evaluating counterfactuals with first-principle physical models such as queueing rather than data-driven machine learning; allocating influence with Shapley values from game theory; the splitting-invariance property that divides each factor into inherited and originated parts to respect causal relationships and fix the symmetry problem; and the decomposition property giving roughly n-log-n complexity in the number of factors of an issue rather than exponential), and the results (deployment on Alibaba Cloud DBaaS for over a year across 15,629 operations, 86 services, and 2,546 machines, an 83.3 percent reduction in system failures, 97.3 percent top-1 root-cause accuracy on production data outperforming baselines by at least 28.7 percent, 98.7 percent on TrainTicket, and 98.6 percent versus a best baseline of 34.0 percent when multiple root causes coexist, compared against baselines including MicroHECL, MicroRCA, MultitierRCA, and MicroRank) are all drawn directly from the paper. Background explanations of microservices, Shapley values, causal graphs, counterfactuals, and queueing models are standard and provided to make the paper’s contribution understandable.