Asklemmy

I actually do... Yes... I have dual internet connections, dedicated power off both phases of my electricity with ~5 hours of battery backup, run redundant internal infrastructure (power, network, and server hardware)... I also have a massive backup library and am currently working on obtaining offsite backups solution. The whole site/house is also monitored with cameras.

I have better uptime than some datacenters in my area have which I can truthfully quantify that as I also hold a CIO/CISO position in another company that operates out of a major Datacenter in my area.

Edit: Should clarify, an offsite backup solution that ISN'T "just peer with backblaze or some other provider" to store your backups. I intend to do a rotating tape library. With one set of tapes always being off site.

Also to mention... I have better uptime than AWS-east at this point of the year... Although there will be some outages of my infrastructure here soon for a network hardware update. I suspect something in the order of about 1 minute of downtime total.

forget Gilfoyle I wanna know what Anton is doing to Chat GPT

What kind of load balancing are you thinking about/looking for?

If we look at Lemmy in specific...

Jobs that a server performs for users on it's platform:
Login services(are you even you to begin with?)
Session Management (being logged in at multiple places, not mixing you up with other users...)
Subscriptions (what content to even show you... organizing them on the page... etc.)
Ban lists (and applying them to what you're looking at)
Peering with the other platforms

Jobs that a server performs for off platform users: Sending ActivityPub messages to the other user's platform.(effectively the same as "peering with other platforms" from above)

The idea is that the jobs that the server has to do for it's local users is actually a lot more both numerically and in taxing tasks than the jobs that one particular instance has to do to send updates to the federated instances... A lot of the list in the first case is a boatload of SQL queries. The activitypub notification is effectively a broadcast of a relatively simple text that doesn't take much bandwidth.

So let's look at actual cases now that we have some ideas of what instances are doing.

I run a small instance, I have a few users (because I purposefully keep it small). If my users only ever interact with the fediverse through my instance, then other instances don't have to do most of the jobs in the top list. I've taken that load from lemmy.ml or other bigger instances that my users would have ultimately migrated to if they didn't have my server. The tradeoff is that my few users now cost the 1 connection for activitypub notifications.

Lets look at a theoretical "perfect" setup... 2,000,000 users across let's say 1,000 instances. Evenly distributed. So each instance has 2,000 users. In that case, any given server would have to serve 2,000 people from the upper list and 999 activitypub broadcasts. This is significantly easier to do than have a single server try to handle all 2,000,000 users on a single instance serving nothing to the activitypub broadcasts.

There's is one caveat with this... activitypub broadcasts will send everything that is subscribed... even if users don't actually view it. So there could be some waste. This then leads to the discussion of well how many users until there's a breakeven in cost of the first list vs the potential waste of the activitypub bandwidth. That answer is debatable... But most people agree that take the discussion seriously that the return on investment could be as low as 2-5 users. I think that the bandwidth cost outweighs the SQL (CPU, RAM, etc...) costs quite handily personally.

Other useful functions that occurs with this setup... As long as I got the ActivityPub message on my server... my users can see all of Lemmy.ml's content. Regardless of if Lemmy.ml is actually running or not. We saw that with the downtime that some of the bigger servers are seeing, all the other instances could still consume the content... Just no updates were being sent.

This is relatively simplistic... I've skipped some nitty gritty stuff... I've simplified some other stuff. But this is the gist.