So, there is a thing with EVE where players have to warn CCP at a 24 hour notice that there is going to be a massive battle in system X.
That way, they can harden that node, allowing for the battle to go smoothly. (Most nodes can't support a 2000 player battle)

Now, it is speculated that the reason they can't distribute the load between nodes is because of backend issues due to the game being from 2003, and most of the code being a gigantic mess.



Now with Legion, if large scale battles are to be supported, you can't require players to warn CCP of imminent battles.
So, is it going to be a problem?
Or can you guys distribute the load between your servers?
Or maybe there is some magic I don't understand?

I would guess that it'd be done differently to what happens in EVE.

Well yes, of course, I doubt they would do what developers from 2003 did.

I'm just making sure if it's going to be a problem or not, because Legion will run off of the same servers and interact with that game from 2003.

You do the same thing anyone does when you need more pow in your power...

WELD MORE SERVERS TO YOUR SERVER!

Pretty sure that they welded a "$50 000" server onto Tranquillity (called Frankenstein) so that Jita wouldn't die of having people in it. It's in one of the old fanfest vids.

The best solution would be to realize on-the-fly node switches so that the server can react to load spikes while preserving the current game state.

The worst what would happen with such a system would be a single lag spike whenever the instance switches to reinforced mode.

The best, best solution would be to have sufficient head room available at all times so that reinforcement is unnecessary in the first place, though running all instances on hardware that is horribly oversized for the load 99% of the time is not the smartest thing to do financially since the overcapacity will not result in any practical advantages.

The "best solution" you referred to will end up being negated eventually as Eve Online's battle history is solid proof of that. Back then servers were not that strong and most battles back then were only able to support up to 500 players at once (TOPS). As the servers began to be upgraded and was able to support more players in one system, suddenly the battles grew in size from 500 to 1,000 strong. Once again, the server had to be upgraded and from 1,000 we went into 3,000 players stronger over the course of just a few years. Even now, with TiDi implemented, people still feel that the servers need to be upgraded. It's a never ending cycle.

It absolutely is. However, the load any server instance (system, map, you name it) puts on the physical machine can vary from essentially nothing, when no one's there and it's just kept running, to OMFGBBQ in cases of good ol' blob warfare with thousands of players.

Because the former scenario, or something very close to it, makes up at least 90% (more like 95-98%) of the time in terms of load per system if you exclude Jita and surroundings, having every single system handled by the best server money can buy is a ridiculous waste of money and energy.

That's why you need some ability to scale the computational power dedicated to every instance. In the case of EVE the current solution is to have most systems be handled in groups per physical machine because that's generally enough.

Only when things go south does CCP start to reserve more, including 100%, of the resources a server blade can offer to make sure you still get the highest performance possible when you need it.

So while, yeah, you have to keep your hardware and software up to date to handle increasingly extreme load scenarios, should they occur, going for maximum performance at all times in every instance is completely infeasible and quite simply useless because the extra power provides zero benefit for the vast majority of time.

Edit: I'm starting to feel that you were talking about the second "solution" and the impossibility of having "enough" resources to begin with because players invariably respond by dumping just more stuff onto the field which is obviously true. Disregard if that's the case.