正直こういう70%ちゃんと動いて30%で性能劣化でpartialリジェクトする系の障害って障害扱いするのも面倒なんだよな
何せちゃんと参加者にリジェクト通知できていれば仕様通りに動いててバグって扱いに出来ないし、
リジェクトが最初から想定されたシステムだと
こういう性能問題みたいな非機能要件は正常判定の範囲をどこまで担保するかって相当経験無いと線引きできないしね

性能の正常判定の範囲を厳しめにとるとAWSだとダイレクトに毎月のコストに反映されるしな

将来プール運営考えてる人に取っては非常に勉強になると思うわ

性能を担保するためのコストをどうやって試算するべきか、高負荷時にどうやってスケーリングするか、オフラインでスケールさせるか、いやオンラインで自動スケーリングだ、みたいなね。

これがSI案件だったらプリセールス部隊がプロジェクト受注可否の境界となる目標予算を顧客のシステムの想定負荷を試算して徹夜・休日返上でシミュレーションするけど、なかなか個人ではそこまでやる気でないわな
客の圧力に負けて下手に安めの予算設定すると、いざ期待してた性能でなかったときに「無償でやれよ、できるって言ったのお前だろ！」ってSI業界あるあるの騒動になるしな

今回はプール参加者は客ってほどのもんでもないからそこまで責任感感じる必要がないのが救いだな
これが仕事だったら心配で夜寝れなくなりそうw