4 ms·

I've more often been surprised how well applications scale in practice that don't follow the scalability guru's advice. Having worked at a couple of places that

I've more often been surprised how well applications scale in practice that don't follow the scalability guru's advice. Having worked at a couple of places that actually needed scaling, I've learned that monoliths written in Java, even using Spring boot (which still sucks imnsho, but for other reasons entirely), can actually handle quite a bit of load, if written even half-decently. (I've seen apps with upwards of 1000 req/s written this way, having p99 response times below 30ms) I've also seen a lot of different setups: Minecraft's backend does absolutely everything right IMO, and their sub-10ms p99.9 response times showed as much as well, and I don't have to tell you Minecraft has quite a few users. Or another client I won't name, that used microservices, Kafka message queues everywhere and the most complex architecture I've ever seen, all in the name of scalability, couldn't even calculate their p99 response times because they didn't even answer 99% of their requests of their requests (that is, >1% of requests were dropped), at loads of about 5 requests per minute. Moral of the story: the big picture tech decisions aren't always as important as you might think, implementation details/quality can make or brake any architecture.

toss1 4y ago
>>can make or brake any architecture. HA! I wanted to see "break" (as in fracture) any architecture, but I think "brake" (as in device for arresting or preventing the motion) works even better here — the details of the code increase 'friction' in the machine and prevent it's efficient motion... Overall, I quite agree; the devil is in the details, and those details can swamp the 'architectural' decisions. Best to get both mostly right vs one 'perfect' and be ruined by overlooking the other.
- amarant 4y ago
  Ha! That was actually a typo I hadn't even noticed, but it actually kinda worked!
semicolon_storm 4y ago
Funny, the general sentiment about Minecraft's backend was the exact opposite back when I was doing server hosting a number of years ago. Maybe that's changed though. At the time at least, it was very clear that Minecraft was written for single player in mind. Nearly everything ran in a single main loop, causing virtually every multiplayer server to only be able to utilized 1 core. This meant most servers couldn't scale beyond ~50 players with vanilla Minecraft. Community optimizations could take this to 200-300, but usually sacrificed something for those performance gains. Then a ton of work went into workarounds like Bungee, which enabled the next-gen Minecraft servers to host thousands of players on a "single" logical server. Of course, the main game loop was actually still single threaded and those thousands of players couldn't truly interact with each other as you would expect with vanilla Minecraft.
- xboxnolifes 4y ago
  I assumed they meant the auth servers or other services (or maybe realms), considering Minecraft's game servers are typically player hosted, total Minecraft players is irrelevant in that context.
  - amarant 4y ago
    You are correct! I was talking about Auth and related services which are hosted by mojang. I never worked with the realms team so I don't have any insight into their codebase, and my insight into the Auth services is dated a couple of years as well, but I don't imagine they've broken it.
karmakaze 4y ago
Scaling monoliths by running multiple webapp instances is the easiest way to scale and works up to the point your shared database instance can't keep up. Your schema and queries matter more than anything else. I wouldn't call this "scale" which is technically correct but not what's usually meant in these types of discussions.

toss1 4y ago

>>can make or brake any architecture. HA! I wanted to see "break" (as in fracture) any architecture, but I think "brake" (as in device for arresting or preventing the motion) works even better here — the details of the code increase 'friction' in the machine and prevent it's efficient motion... Overall, I quite agree; the devil is in the details, and those details can swamp the 'architectural' decisions. Best to get both mostly right vs one 'perfect' and be ruined by overlooking the other.

amarant 4y ago
Ha! That was actually a typo I hadn't even noticed, but it actually kinda worked!

semicolon_storm 4y ago

Funny, the general sentiment about Minecraft's backend was the exact opposite back when I was doing server hosting a number of years ago. Maybe that's changed though. At the time at least, it was very clear that Minecraft was written for single player in mind. Nearly everything ran in a single main loop, causing virtually every multiplayer server to only be able to utilized 1 core. This meant most servers couldn't scale beyond ~50 players with vanilla Minecraft. Community optimizations could take this to 200-300, but usually sacrificed something for those performance gains. Then a ton of work went into workarounds like Bungee, which enabled the next-gen Minecraft servers to host thousands of players on a "single" logical server. Of course, the main game loop was actually still single threaded and those thousands of players couldn't truly interact with each other as you would expect with vanilla Minecraft.

xboxnolifes 4y ago
I assumed they meant the auth servers or other services (or maybe realms), considering Minecraft's game servers are typically player hosted, total Minecraft players is irrelevant in that context.
- amarant 4y ago
  You are correct! I was talking about Auth and related services which are hosted by mojang. I never worked with the realms team so I don't have any insight into their codebase, and my insight into the Auth services is dated a couple of years as well, but I don't imagine they've broken it.

karmakaze 4y ago

Scaling monoliths by running multiple webapp instances is the easiest way to scale and works up to the point your shared database instance can't keep up. Your schema and queries matter more than anything else. I wouldn't call this "scale" which is technically correct but not what's usually meant in these types of discussions.