Hey #devs, what do you think of this discussion of scaling issues with Mastodon? Is this mostly a fair take, iyo?
https://lukas.zapletalovi.com/posts/2022/why-mastodon-instances-are-difficult-to-scale/
@shoq Yes, from what I understand of how Mastodon handles its decentralized infrastructure, more users/servers means exponentially more data, which means slower load times and more money spent by server owners.
In theory, you'd like the decentralized servers to balance the load. But instead, Mastodon is designed to store inboxes locally on each server, so each server has to store not only its own data, but also the data that other servers have pushed to it (i.e. the feeds you subscribe to). It's redundant and expensive, but the reason they did it (presumably) is because content from a server won't entirely vanish if that server vanishes.
@LouisIngenthron Yep, and it's always bugged me. All this redundancy and inefficiency mainly because of some storied fear that precious data could be dropped or intercepted. If federations were all of limited size, it's makes sense. At a global scale, it's probably unworkable.
@shoq @LouisIngenthron probably needs some happy medium of caching such data. Always fetching (redundant) data instead of storing would have its own latency, scalability and cost issues
@pixelpusher220 @shoq Right, but the best way to do that... is centralized caching infrastructure.
@LouisIngenthron @shoq 'best' will differ depending on the specific requirements of a given scenario.
I could see large instances being candidates for such semi centralized caching nodes.
In the interim, having instances cache only recently accessed data vs *all* such data would be an improvement.