> but it makes me wonder if there's a fundamental problem with the design of Mastodon.

I also note the article says,

> During the month of November we averaged 36.86 Mbps in traffic with samples taken every hour

That seems like a large amount of bandwidth to service 30,000 users (who knows what fraction of them are actually active at any given moment). But I guess there's going to be a lot of video and image content. I have tried searching all of their linked blog posts about scaling but can't find any number that might map to requests per second without making huge assumptions.

As a point of reference, look at what Stack Overflow is run on. As a caveat, SO is probably more read-heavy than Mastodon, but it also serves several orders of magnitude more volume (on a normal day in 2016 they would serve 209,420,973 HTTP requests[0]). They did this on 4 DB servers and 11 web servers. And in fact, it can (and has) worked serving this volume of traffic on only a single server.

With this setup SO was not even close to maxing out their hardware (servers were under 10% load, approximately). SO also listed their server hardware[1] in 2016. I don't know enough about server hardware to assess the difference, but to my eye they look similar on the web tier with similar amounts of memory, similar disk, etc.

I'm not saying Hachyderm is doing anything wrong, but it makes me wonder if there's a fundamental problem with the design of Mastodon. And to be clear I understand that this particular issue was caused by a disk failure, but that they even had this hardware in place running Hachyderm is surprising to me.

[0] https://nickcraver.com/blog/2016/02/17/stack-overflow-the-ar...

[1] https://nickcraver.com/blog/2016/03/29/stack-overflow-the-ha...

There's no tragedy here. Let's be absolutely clear - every single person who lost money in this abomination was as greedy as SBF, trying to milk a cryptocurrency ecosystem they never believed in nor understood.

* Make your software observable. Your feature is not finished until you've verified it is being used as expected. Ideally you should have all of the data you need to know if things are going well without having to wait for customers to email you with complaints. Be careful not to develop a culture of developers throwing code "over the fence", either to QA staff or a release team - developers own their code from IDE to production.

If you don't develop this culture of ownership you end up with longer feedback loops between customer support, QA and dev.

"Women's sports are for women, not men pretending to be women"

It is not hard to find many more cases and of course the vast majority of banned accounts belong to people with no public profile and you'll never hear about them.

[1] https://www.pbs.org/newshour/politics/twitter-suspends-u-s-s...

This has nothing to do with Apple's kafkaesque review process and everything to do with their policies, which have been increasingly strictly enforced for the last couple of years.

Can you expand on this? According to the article the ads are privacy-preserving but I'm open to hearing otherwise. There's not a lot of detail in the article.

> Ads will give users the option to use our independent search engine with ads that don’t track them, or to sign up for ad-free paid search

Are you willing to put your money where your mouth is? Or do you expect software companies to work for free? (Presumably not the companies you work for).

That's a long time to have a sword dangling over your head. These employees are going to be under tremendous stress for at least a couple of months.