BUILD → BREAK → OBSERVE → REASON
処理の上限と、保存した事実。プロダクトの設計を、小さい実験で考える。
STEPS 19 / 23 / 26 · M5 / M6
実行枠が空いていれば実行へ。満員なら待ち行列へ。両方いっぱいなら受付を断る。まず6件を一度に送ると、何件が受け付けられるか予想しよう。
設定を変えると、この実験の状態を初期化します。
受付済み0
完了0
取消0
受付を拒否0
処理する速度が追いつかない時、待つ仕事がメモリと時間を消費する。受付・実行・待ち行列にそれぞれ上限が必要。asyncは待ち時間を他の仕事へ使う仕組みで、CPUやDBの容量を無限にはしない。
Rustの小さい実験: cargo run -p trail --example bounded_queue。この例は待ち行列の容量を扱い、ワーカー実行枠はまだ実装していない。
STEPS 16 / 24 / 25 · M7 / M8
要求 request-001 が保存された直後、成功の応答だけを失う。同じ要求を再送した時、記録は何件になるだろう？
条件を変えると、この実験だけを初期化します。
記録はまだない
要求ID: 未保存
まだ送っていない
これは同じ保存先で同じ要求IDを再利用する例。要求IDの寿命、同じIDで異なる内容が来た時の拒否、記録とIDのtransaction、再起動後の復旧を実装する必要がある。外部へのメールや別サービスへの書き込みは、そのDB transactionだけではまとめられない。
プラクティス: ex09 の上限付きbackoff、ex10 の重複除去。その後、第24段階で再起動を越えるキーの保存と条件付き更新を実装する。