Seems to me the fear of overloading one instance over another will not happen after all.
But I do hope the Threadiverse can hit 500,000 consistent active users by the end of summer.
Give me that hopium guys! 💉
Seems to me the fear of overloading one instance over another will not happen after all.
But I do hope the Threadiverse can hit 500,000 consistent active users by the end of summer.
Give me that hopium guys! 💉
I believe that your own instance pulls the feed from the other instance, so you’re not actually browsing that other instance directly. If other users on your local instance are also subscribed to that particular community, then your local instance is already syncing the feed. Essentially, I believe that each federated instance replicates a copy of the other instances’ communities, if and when those communities are requested or subscribed to by a user on the local instance. Hope that makes sense, and if anyone has a better (or more accurate) explanation, please feel free to correct me.
Think that’s more or less correct, but regarding @drturtle@lemmy.world’s question about overloading, I think that it may affect folks even on other instances if Lemmy.world’s overloading affects its response time to other servers attempting to sync with it.
E.g. Lemmy.world is bogged down -> Lemm.ee tries to sync posts/comments from .world -> .world takes a longer time to fulfill the request -> Lemm.ee sees older posts/comments for awhile until .world catches up to requests.
Glad to hear I’m not totally off the mark. I wonder then if instance-to-instance transactions would cause less overall congestion than local user traffic in such cases.
For example, if there are 25,000 users spread across 5 instances (with some overlap in community participation), would the instance-to-instance transactions needed to facilitate these users result in less of a performance hit than having all 25,000 users on the same instance? I don’t know nearly enough about databases to make an educated guess.