This site is currently struggling to handle the amount of new users. I have already upgraded the server, but it will go down regardless if half of Reddit tries to join.
However Lemmy is federated software, meaning you can interact seamlessly with communities on other instances like beehaw.org or lemmy.one. The documentation explains in more detail how this works. Use the instance list to find one where you can register. Then use the Community Browser to find interesting communities. Paste the community url into the search field to follow it.
You can help other Reddit refugees by inviting them to the same Lemmy instance where you joined. This way we can spread the load across many different servers. And users with similar interests will end up together on the same instances. Others on the same instance can also automatically see posts from all the communities that you follow.
Edit: If you moderate a large subreddit, do not link your users directly to lemmy.ml in your announcements. That way the server will only go down sooner.
I think lemmy will be bitten in the ass by not having considered clustering/horizontal scaling from the start. Federation alone as a scaling mechanism is only feasible for "nerds". But if the network wants to grow, we will need a few scale-able large hosted instances. And if their only choice is to scale vertically, there will be a hard limit (unless we put a good old Mainframe somewhere ^^).
Another downside of this design is: you can't run it with high availability. If there's only one process per instance, updating it will mean the whole instance is down. Sure, if all goes well this downtime is under a second. But if it doesn't go well or if a migration is needed, this might quickly become hours.
Indeed. If a big instance like lemmy.ml was to be shut down all the communities would be lost. This is simply not sustainable. Why would users put effort building a community if it could be gone at any time?
That however would be a different problem. A horizontally scaled instance would be able to cope with more users, but if it shuts down for monetary, personal, or whatever reason, it's still down.
Protecting a community from this is what the decentralized part is for. That is already in place.
(Although there is a middle ground where you could design the system in a way that one instance is mirrored and load-balanced across different hosters. That would actually also be quite interesting to have. But that's another layer of complexity on top.)
I still don’t quite understand how the community is replicated…
Are you saying that if Lemmy.ml/tiki exists and someone creates Beehaw.org/tiki that they are the same community? They would show the same posts and comments?
Or are they completely separate communities that would just have the same name… users could subscribe to both if they wanted, but the posts and comments would be stuck on their respective instances?
Or - Is it the case that Lemmy.ml’s tiki community and posts and comments are also stored on Beehaw.org somehow?
If I deleted the tiki community on Lemmy.ml, would users from both communities lose their posts and comments from the Lemmy.ml instance of that community?
The current state is that they are separate communities, but I believe the person you're replying to is proposing something like the other option, where some communities would be the same across instances so that the community and its post history would survive if one of the instances went down (not currently the case).
Currently, if you deleted the tiki community on lemmy.ml, only the lemmy.ml tiki community posts/comments would be gone. Any other tiki communities on other instances would remain.
The Tiki community should simply run a Tiki server, no? Problem solved.
Great idea, but then I'd have to get into the whole hosting thing and all of that which I don't want to do.
There may be someone in the community that's interested and/or willing.
But i agree, it's not as simple as it sounds.