Even the most cursory security review for a "client software communicates with server software over the public internet" type of app should include determining whether or not the app will be easy for a script kiddie who knows the app's endpoint to DOS it. At the very least they would have noted that it ran like crap when they fired up some automated testing tool and promptly bogged down the app.
My understanding is that their back end could not handle the traffic volume. That is functionally equivalent to being DOS'd. Regardless of whether or not the people making the requests want them to be served or just want to waste your resources the legitimate requests were not served. Down is down.
A DOS attack isn't exactly a good way of doing a back end stress test. You could survive that by hiding behind cloudflare or something ... still have your back end buckle with legitimate traffic.
A staged DOS is exactly how you perform a back end stress test actually. This is industry standard. It's what testers do every time we want to know when our systems give up and fall over. The key is doing it on a prod like environment before going live.
Your "legitimate traffic" for a finite population of intended users should by definition not be capable of compromising the capacity of your system to operate if you have allocated your resources correctly unless your fundamental implementation is unsound.
Any excess traffic beyond a modest multiple of your expected turnout (I.e. worst case scenario where every citizen of Iowa decides to attend the primary) would by definition be either potential tampering via fuzzing by unintended actors trying to inundate servers to drown out or frustrate your expected userbase,or the most accident/mistake prone gaggle of users ever.
Not saying that happened or that I've seen anything that says it did, I just find your assertion odd that you'd think that a staged DOS in the testing phase against your infrastructure isn't how performance testing works.
True, there's many ways to stop a DOS that can't be used to survive legitimate traffic but in any case a well rounded security test for an application that's uptime sensitive will probably determine performance bounds for the application. You kind of need to do that in order to cover your ass when the client inevitable installs it in a different kind of black box than tested it for.
