We are digital librarians. Among us are represented the various reasons to keep data -- legal requirements, competitive requirements, uncertainty of permanence of cloud services, distaste for transmitting your data externally (e.g. government or corporate espionage), cultural and familial archivists, internet collapse preppers, and people who do it themselves so they're sure it's done right. Everyone has their reasons for curating the data they have decided to keep (either forever or For A Damn Long Time (tm) ). Along the way we have sought out like-minded individuals to exchange strategies, war stories, and cautionary tales of failures.
You can always look to implement webtorrent. It does not work everywhere, but it works very well.
Basically how it works it's that you have a streemable file, you make a torrent, and a javascript client on the browser it's capable of downloading and streaming it.
From the live video delivery, this is definitely above my expertise, though it sounds like a fun problem to have. Suffering from success and all that.
The only bit I can contribute is automated deployment is your friend. Many providers will allow very easy to use scripted deployment. I don't know what kind of computer power you need to push, but a VPS with a Gb (in theory) pipe is very cheap, and if you need more more powerful VPS or bare metal a lot of providers allow hourly billing, some even hourly billing for bare metal if you need a lot of compute with it- some providers will not take kindly to you pounding a shared compute instance at 100% CPU. What you should look into do is automated deployment...may k8s, maybe something else. Before you start a stream that might have that many viewers, you can just deploy like 40 instances. You don't even have to worry about bandwidth with most providers since you're just running a short time. When your stream is over, all of the instances are destroyed and the billing is stopped to the nearest hour.
You can seriously do what you need for a couple hours for a few bucks if you don't need a bunch of compute, more if you need compute but still very reasonable. The non-compute heavy go 1Gb/s connections as low as not even a whole cent an hour, and you can distribute this across multiple providers to give more geographic locations.
The one caution I would give with this method is before you invest time in making a platform work for your setup is to actually grab an instance manually and benchmark the connection. Some are 1Gb/s, but will throttle to less during peak times, so test over time too. Know what you are dealing with and how many instances you need.
Use a more efficient type of video codec / audio. Going from basic hardware encoded H.264 to something like x264 can increase efficiency greatly. I have no idea what your setup is. Or moving onto VP9/AV1/H.265
H.264 and x264 are the same thing. H.264 is the name of the math standard. x264 is the name of an open source software that implemented that math.
I wouldn’t expect a server crash from bandwidth limitations. A few questions: Do you have metrics on the bandwidth saturation and server resources? Have you isolated the issue to be certainly with bandwidth?
All the time whenever the crash happens, bandwidth usage goes up all the way and website stops responding.
Out-of-the-box solution: implement a queue on your website. As soon as it hits 7k viewers, new viewers must wait in a queue until older sessions have closed. They do the same for popular MMOs.
You are going to need some CDN relays or something. 30k live viewers will destroy a single connection.
Maybe you need multiple servers to handle the demand with a load balancer.
Raise the price until have less than 8k viewers.
Why are you trying to do it the hard way?
If you're looking for an out of the box solution you could just throw it at CloudFlare Stream.
https://www.cloudflare.com/en-au/products/cloudflare-stream/