生み出したいという場合に、システムが詰まって死なない実装を考えたので、その実装をまとめてみた。そんな記事になります。4系を使ったアプリケーションの、商品の在庫管理の一例を提示するものです。カラムを持つがあるとします。商品の購入が発生した際にpurchasesのレコードを作成し、購入があったitemsのレコードのstockを購入数分decrementする。itemsレコードをロックして必ず購入数分だけ在庫を減らさないといけない。排他制御(楽観ロック・悲観ロック)の基礎なので、レコードをロックする必要があります。安易にロックしてしまうと、前述の通り大量にアクセスがある前提なので、ロックの解除待ちが発生してしまいます。なると読み込みすらロックしてしまい、商品の詳細ページの閲覧すら遅延します。迎えるコネクションプールの限界。サーバーダウン....これを回避したいのです。他の商品に影響は出したくない在庫数をこえて注文を受けてはいけないというのを想定していました。3人よれば文殊の知恵。いう設計を考えました!実装の仕組み実装としてはそんなに難しいことはないんです。図にすると...こんな感じです。在庫数を増やす時はその数だけstocksレコードをcreateする。売れた数だけレコードをdeleteする。削除のロジックは下記の通り。購入処理のレコードロックの影響を受けない在庫がない時はレコードがないときなので、判断しやすい数値で在庫数を守っていると一番困るのが在庫数を増やすときですね。レコードロックされている可能性もあるし、増加させる処理もしっかり書かないといけない。その分、createするかdeleteするかなので、レコードによる在庫管理は非常に楽ちんです。在庫レコードをランダムに取得することができればロックを回避できそうな気がします。大量にレコードがある時はロックするレコード自体をランダムに出来るのでロックにかかる時間を削減できそうです。5系から追加されたようです。同時実行を意識した処理になった!ただ、この場合でもstocksテーブルは別で作ったほうが良いかもしれないですね。itemsに在庫情報を持ったままだと、(処理にもよりますが)トランザクションに巻き込んでしまい、結局ロックしてしまい読み込み待ちになるのは怖いので。総括ということで、在庫をデータとして抱える方法の一つの解でした。この設計を取り入れたサービスは想定していたよりずっと安定可動しています。数値で在庫を管理するより速度的に良いとかそういうことはないですが、目立った問題もなく動いているのは嬉しいですね。在庫のデータを持つのが数字じゃない方法が望まれている!!という状況に遭遇したら是非、参考にしてください!それでは、また。Hacking!株式会社ベーシックエンジニア募集QiitaWantedly。