HTTPプロトコルの応答ステータスにおいて、Service Unavailableというのがあります。
以下は、 https://developer.mozilla.org/ja/docs/Web/HTTP/Status/503 を引用しています。
HyperText Transfer Protocol (HTTP) の
503 Service Unavailableサーバーエラーレスポンスコードで、サーバーがリクエストを処理する準備ができていないことを示します。
一般的な原因は、サーバーがメンテナンス中のために停止していることや、過負荷状態になっていることです。このレスポンスは、一時的な条件に使用する必要があり、Retry-AfterHTTP ヘッダーには、もし可能であれば、サービスの復旧に要する予想時間を含めるべきです。
メモ: このレスポンスと共に、問題を分かりやすく説明するページを送信する必要があります。
503 のステータスはしばしば一時的な状態であり、レスポンスは頻繁にキャッシュされるべきではないため、このレスポンスと共に送信されるキャッシュ関連のヘッダーは注意する必要があります。
最近関わった３つのサーバの全てが混雑時に５０３を返しています。楽天チケット、LivePocket、ASICS Tigerです。
上記３つのサーバは、発売時刻と同時に５０３のアクセス制限となるのですが、一定時間が経過すると、アクセス制限が解除されて、通常のアクセスができるようになります。
アクセス制限が掛かると、恐らく一律制限が掛かるため、持久戦の状態になります。サーバが処理することが可能なアクセス数になるまで制限をかけています。アクセス数がしきい値を下回ると、アクセス制限が解除されるという感じです。（あくまで私感です。）
このような仕様にするメリットは、比較的能力が低いサーバでも運用が可能になるという点があります。ユーザビリティは最悪ですけどね！！
週末はASICS Tigerのコラボ商品に参戦していました。
初めての参戦ということもあって、サーバの勝手が分かっておらず、リトライ処理が不十分だったのですが、ユーザがそれを補うマクロを作ってリストックしていましたｗｗｗ
ものの５分ぐらいで対応していて、いろんな状況に臨機応変に対応するところが流石です。
ただし、動画のような処理は、本来であればBOTが搭載すべき機能のため、今後の改善・対策内容に盛り込みます。