MangaDex infrastructure overview

They mention a $1,500 budget per month but then omit things critical to understanding how they achieve that cost point.

What is actually more interesting is to understand what portion is spent on servers versus bandwidth - and what hardware configuration they use to host the site. For example, Is $1,500/mo just paying for colo costs + bandwidth, with already owned recycled hardware (think last gen hardware that you can get at steep discounts from eBay / used hardware resellers...)

That would have been way more interesting to know given the blog title than the choice of infrastructure software they use.

Premium plan on content that can be considered as dubious in copyright context? Seems like a quick way to get shut down.

Not familiar with the project but it is great to see a counterpart to over-provisioned enterprise infrastructure. $10 in 2021 can do what $100 in 2011 did, what $1000 in 2001 did, and that is not solely due to hardware. Well-designed deployments of K8s, KVM/LXC, Ceph, LBs like this project can handle so much more traffic than poorly configured Wordpress storefronts.

They're using battle-tested tech from Redis and RabbitMQ to Ansible and Grafana. Nothing super fancy, nothing used just for the sake of being modern. Not sure how long it took them to end up with this architecture but it doesn't look like a new dev would have a hard time getting familiar with how everything works.

Would definitely like to hear more about their dev environment, how it is different from prod, and how they handle the differences.

> Regarding DMCA’s, as an entity doing business where they’re legal, what should they do as a middle man?

Don't use them and instead have your middleman be in a country that ignores intellectual property rights and copyright?

I'm not saying CF is wrong to pass them through. I'm just saying CF is not the right choice for a warez site for longevity.

I've done things at scale (5-10K req/s) on a budget ($1000 USD) and I've done things at much smaller scales that required a much larger budget.

_How_ you hit scale on a budget is one part of the equation. The other part is: what you're doing.

Off the top of my head, the "how" will often involve the following (just to list a few):

1 - Baremetal

2 - Cache

3 - Denormalize

4 - Append-only

5 - Shard

6 - Performance focused clients/api

7 - Async / background everything

These strategies work _really_ well for catalog-type systems: amazon.com, wiki, shopify, spotify, stackoverflow. The list is virtually endless.

But it doesn't take much more complexity for it to become more difficult/expensive.

Twitter's a good example. Forget twitter-scale, just imagine you've outgrown what 1 single DB server can do, how do you scale? You can't shard on the `author_id` because the hot path isn't "get all my tweets", the hot path is "get all the tweets of the people I follow". If you shard on `author_id`, you now need to visit N shards. To optimize the hot path, you need to duplicate tweets into each "recipient" shard so that you can do: "select tweet from tweets where recipient_id = $1 order by created desc limit 50". But this duplication is never going to be cheap (to compute or store).

(At twitter's scale, even though it's a simple graph, you have the case of people with millions of followers which probably need special handling. I assume this involves a server-side merge of "tweets from normal people" & RAM["tweets from the popular people"].)