Perhaps someone can enlighten me and just to clarify I don’t know the full technicalities of this issue and what i’m about to say is theoretical but worrying if applicable.
With OpenChat recently announcing they are scaling across multiple subnets, I am curious to how this affects other dapps in the same subnet. I imagine scaling your application to another subnet is not easy.
So if one particular application is experiencing mass user growth e.g OpenChat - will this put all the other dapps in the same subnet in a position of not being able to store any more state until they also figure a way to scale across subnets - requiring an unnecessary amount of development time for the team in this scenario.
Essentially I am worried we are not prepared for mass growth if dapps begin to scale and fill subnets, and to be candid: whats stopping one dapp from filling all subnets with data, and rendering all other dapps useless?
The best defense mechanism for full subnets is subnet splitting. Subnet Splitting forum post is here, closely adjacent is Canister Groups with this forum post.
It entirely depends on your requirements. The biggest issues for OC are probably performance (XNet calls take longer than calls on the same subnet), and changing the subnet on which they create new canisters. I’d bet with OC’s experience people will quickly figure out some best practices to prevent such issues from appearing thanks to better architecture choices early on.
Cost, even though storage is cheap it still takes a decent amount of money, and the ability to create new subnets basically on-demand. Looking at the dashboard, there’s currently 700 nodes ready to go that are not assigned to a subnet yet.
As Severin mentioned, the main issue with scaling across subnets is the additional latency (equivalent to 2x the latency of an ingress message). The upshot is that it is all transparent to your canister, there is nothing that it needs to do differently to communicate with a canister on a different subnet vs a canister on the same subnet.
Meaning that in theory (and if you ignore the latency; or work around it by efficiently sharding your data across subnets) all you need to do in order to work around any resource limitations on your current subnet is to use a cycles wallet canister on a different subnet to create new canisters there.
And finally, once subnet splitting is fully implemented (and in extreme situations even before, with extra manual work) subnets will not be allowed to reach their resource limits. Initially manually and later automatically, subnets nearing resource limits will be split before this causes issues for dapps. Canister Groups are intended precisely to allow for clean splitting of subnets without splitting of dapps across subnets, where possible. (We have the logic for splitting a subnet’s replicated state and we’ve already ran a couple of successful tests. The missing part, which we will start working on, is orchestration.)