As a product manager, I want to understand the potential benefits (or lack of) to WDQS stability and user timeouts from splitting and federating Wikidata subgraphs, so I can decide whether to split the graph, and the best way to do so to improve WDQS stability and functionality.

Based on what we know about the structure of Wikidata's subgraphs (https://wikitech.wikimedia.org/wiki/User:AKhatun/Wikidata_Subgraph_Analysis) and the queries on them (https://wikitech.wikimedia.org/wiki/User:AKhatun/Wikidata_Subgraph_Query_Analysis), what is the expected benefit (or a very rough estimate) of splitting the Wikidata graph into some number of subgraphs that can be federated? Primarily, how might federation affect:

• total query timeouts
• total query time
• stability of WDQS (CPU load? TBD what the best metric is)

There are many ways to split the graph, and we do not need to consider all of the possibilities, but we should consider the ones most likely to help WDQS be more stable, and reduce the number of timeouts on the service.

AC

• for different graph splits that are likely to help reduce WDQS load, quantify the potential benefits of federation based on total timeouts, query time, and WDQS load

Out of scope
This ticket does not take into account the fact that splitting subgraphs will improve WDQS scalability by reducing overall graph size, which is currently a risk for Blazegraph.