* You want them to be as fast as possible (ideally: instantaneous)
* You want them to be validated (long-poll to a third party validation service)
* You need them to be sequentially auditable (this is a "... or you could go to jail" requirement)
* If a failure occurs, you don't want to be out your own money
While these are solvable, it's the reason that so many cloud services suddenly hit scaling issues at the payments layer: things are going great and then that layer gets involved and "oops, hold on, we're waiting on Visa's servers. Still waiting. Stillllll waiiiiiting..........." Or the team was certain they'd simultaneously solved speed and sequential auditability this time but, oops, there's yet another sequencing point that's actually a bottleneck.
I think pay to view events might have hardest time as then there is actual need to be available at that exact time.
True, though many of them have at least an hour or two of intro/opening ceremony/commentary to troubleshoot as people slowly join, so it's not the end of the world if the stream crashes up top.
Bad planning, maybe but definitely not a conspiracy against the game.
No-preorders is basically same as no-capes. Just don't do it.
But you have a bunch of people on HN opposed to it for no good reason other than "IPv4 works for me™".
This makes sense because there are several live service games on steam that have hundreds of thousands of active players - any update will put a large instantaneous load on the CDN as all the clients are forced to update at the same time, and this happens extremely frequently so they've had to get good at handling it.
What doesn't happen very frequently is hundreds of thousands of people trying to buy a game at exactly the same time, because most games have pre-orders.