決済システムの残高管理周りの DB 設計と戦略 - カンム テックブログ

エンジニアの佐野です。今日はカンムの決済システムでユーザの残高管理をどうやっているかについて書きます。 カンムの製品であるバンドルカードはプリペイド方式のカードです。ユーザによる入金、店舗での利用、運営事由の操作などによりユーザの残高が増減します。このような残高の管理について単純に考えると user_id と balance と updated_at あたりをもったテーブルを用意して balance と updated_at を更新していく方法があるかもしれません。しかしながらカンムでは残高を管理するテーブルを持たず、これらイベントの履歴のみで残高を管理しています。以下、本記事ではこれらユーザの残高が増減するイベントのことをトランザクションと呼びます。ここでは DB の Transaction Processing を意味しません。 本記事のポイントは 残高を管理をするテーブルは作らず、ト

[gowithyou]

決済システムはバグや障害による残高誤りは絶対に認められないミッションクリティカルなものなんだから、気軽に残高更新しろとかいうコメントは決済システムを分かっていない。こういう設計がベストプラクティスだよ

[inose660]

プリペイドだから成り立つ側面もありそう。普通のカードで何とかPayに紐付いていると決済回数が激増するし、リボやキャッシングが絡むと深い与信確認や不正検知にも耐える必要がある。でも『論より証拠』の良記事！

[stakme]

メモリに全部乗ってるあいだはいいとしてディスクから都度取りに行くようになるとIO詰まってしめやかに死にそう、スナップショット方式にしてもバッチ追いつかないと死にそう、決済は大変そうだぜ…となりました

[sin20xx]

この手のサービスを実際に開発運用してみると分かるよ。残高という値を保持するリスクは並列処理のリスクも含めバグの温床になる。同一アカウントの並列処理自体は古の技で安全に処理できるので問題にはならないのよ

[Kil]

今のDB性能なら余裕って話だよな。10年20年前のRDBでsum取るイメージだけで否定するベテランはそれなりにいそう。（そしてそのタイプは実行計画見せても否定しそう）

[tagomoris]

トランザクションの発生頻度見積もりを外すと(そういう方向にピボットすると)考え直す必要はありそうだが

[htnmiki]

SUM方式と残高DBを議論した議事録を見たいな。SUM派DB派どちらもいただろうし。

[turanukimaru]

最初にindex利かせたidを直接指定するクエリを投げられるなら union all しようが sum しようが実用的には遅くならない。条件指定した複数ユーザの残高を sum とかすると多分死ぬ。id 直指定はチューンとか不要なくらい速い。

[vuy]

金の流れを追わなきゃいけない事態が発生するだろうしイベントを積み上げる設計はシステム/ビジネスのどちらから見ても理にかなってると思った。

[fai_fx]

会員1人が年間に決済を行う回数を考えると、都度計算でも良いという感じか…。年度で締めれば、無限に増えることもなく。

[W53SA]

スナップショットテーブルの話を見て通帳の一括記帳を連想した

[nekoruri]

結局時系列データをきちんと管理したければ信頼できるイベントストアに基づくイベントソーシングが大正義ってことだなあ

[makky55makky55]

あとで読み直そう。

[kanu-orz]

その昔、在庫管理で似たようなことを考えたことがあった。今ならどう設計するだろう…

[tmatsuu]

わいわい。スナップショットはcreated_atがrangeになるからもしかしたら遅くなりそう。悩ましいところだ。自分が実装するなら年単位でテーブル分けるとかだな。

[motchang]

有高計算するのに全明細舐めるハメにならんか？報告系は別かね？

[ouest]

こういう設計もあるんだよってこと。これにプラスアルファするかな。

[kazuhooku]

マテリアライズドビュー使うとか、そういうトリガー書くわけにはいかんにゃろか

[t_f_m]

あとで

[tumo300-500]

`スナップショット方式` で時間で絞ってるのがややナイーブにみえる。まぁこれやるときはメンテ入れるから OK ってことかな

[Ehren]

要件に依存するよねん

[ntstn]

こういうところは大手のしっかりしたシステムを使おうと思いました。実装はじぶんのとこでしない。

[NOV1975]

残高をトランザクションで積む＝過去データすべて必要ってならんの？てか、トランザクションデータの中に取引後残高もっておけばよくね？（取消でレコード削除せんのであればそれでよいよね）。

[frkw2004]

残高見るのにビューを用意してたりするのかな？マテリアライズドビューで作っておけばよさそう。

[equilibrista]

あとで読む

[hitotakuchan]

排他制御をどうやってるのか不明。それがちゃんとできてないならバグってる。すべてのテーブルをロックして transaction の分離レベルを適切に設定すれば大丈夫なのかな？

[hope_ring]

すばらしい知見の共有ありがとうございます。DBサイズが巨大化したときの案がちゃんとあるのが良い。自分が触ったことあるのはこの巨大化したときの形式だった

[kenzy_n]

固いところのDB設計

[gothedistance]

面白いこれ...

[suginoy]

ファウラーのAccountパターンだと暗に言ってるな。

[reiki4040]

ABとかLBはないけど、自分も入金と出金の記録だけで残高管理するのを同じような設計してて、スケールの対処案まで同様の思考を辿ってるのが面白い

[aa_R_waiwai]

id:onesplat 履歴テーブルから算出できるなら、それが安全だと思う。正規化の問題。部門テーブルがあるのに、usersに部門IDではなく部門名を持たせるのは無意味。もちろん、目的があるなら全否定される設計でもないが。

[morimarii]

残高的なものは設けないのが正統派な気がするけど状況によっては設けなきゃいけない場面もあるので難易度高いと思う

[hirorinya]

学び

[letitride]

取引履歴を残すのは当然の設計として、sumした結果が負数を許容できるか否かかな。許容できない場合、どのリソースでロックを取るか考える必要がある。残高不足はアップデート失敗させるのが楽だったりはする。

[ronnytan]

同時に複数のオーソリが発生した場合、決済金額が残高を超えないかのチェックを、どのように実施しているのか知りたい。

[spark7]

立ち位置のよく分からんバンドルカードか

[lorenz_sys]

自分がWMSの入出庫～在庫に関する設計をした時の考え方・検証方法にほぼ同じ。物流系もミッションクリティカルなので全取引履歴を保持する必要があるがスナップショットがないと実用にならないので併用方式とした。

[toritori0318]

なるほど。たしかにカード単位の残高管理ならある程度がんばれそう