バッジ機能の判定処理はどこに書くべき？

Question

teratailのように「回答者Lv3」みたいなバッジ機能の実装方法についての質問です。

例えば、回答数が100回に達すると「回答者マスター」という一番上位のバッジがユーザーに与えられるとします。

この場合、ユーザーがコメントを実行した直後に毎回、累積回答数が何回かを判定しているのでしょうか？
つまり、データベースにユーザーが投稿したコメントを登録した直後に、そのユーザーの累積回答数を調べて、一定回数以上超えているかどうかをチェックして、認定条件を満たしているかどうかを判定しているのでしょうか？

その場合だと、既に回答数が100回超えている人に対しても、毎回、回答数のチェックと認定条件判定処理が走ってしまい、不効率なような気がするのですが、どのようにバッジ機能の判定部分って実装するのが良いのでしょうか？

Answer 1

データベースやクラス設計のレベルでは、毎回集計するというのが正解です。
そうすると、数え間違い（つまりバグ）がないからです。

しかし、そのせいでサービスが重くなり、質が下がったり、料金がかかったりでは意味がありません。誰も使わない美しいシステムにはなんの価値もないからです。

もし、影響が出るほどであれば集計のタイミングをトランザクションが多くない時間にバッチ処理で回すとか、サマリーデータを保持するとかの対策を組むとよいでしょう。初めから問題になることが証明できるなら最初からサマリーを使ってもよいと思います。しかし、私なら問題ないうちは放っておきます。

実際の負荷を計測して判定するのがあるべき姿ではないでしょうか。

Comments

[退会済みユーザー]

ご回答ありがとうございます。

皆様の回答をみてると、たいして気にするようなことでも無いのですね。

[iwamoto_takaaki]

シンプルさを可能な限り保つことが大事。"You ain't gonna need it"
https://ja.wikipedia.org/wiki/YAGNI
https://ja.wikipedia.org/wiki/KISS%E3%81%AE%E5%8E%9F%E5%89%87

Answer 2

うーん、僕なら統計テーブル作ってそこに足し算していきますかね

Teratail風なら…
１．各アクションに応じて統計サービスにイベントを送信
２．統計サービスが統計を更新して完了通知をバッジ生成サービスに送信
３．バッジ生成サービスが統計情報を判断してスタッフのバッジ情報にバッジを追加

というような感じで、アクションに対して２～３の動作を非同期なバックグラウンドサービスとして実装しますかね

統計サービスは単にアクションに対応する統計を１増やすだけです。
実際に過去のデータを集計したりはしません。
（※不整合が見つかった時だけ対処するようにバッチ処理は行うと思いますけどね）

Comments

[退会済みユーザー]

ご回答ありがとうございます！
なるほどー！

非同期で実行すれば、仮に諸々の判定絡みの処理がバッジ認定済みにとって既に不要なものになっていても、待機時間に影響しなくなって良さそうですね。

大変参考になりました！

Answer 3

1ユーザの累積回答数などたかが知れているので、
カウントしても問題ありません。

方法は考えればいくらでもあります。
バッチを管理するテーブルを作って、
それを検索すれば、ユーザがどのバッチを持っているかは分かります。

回答数が知りたければ、
回答を管理するテーブルに回答数を入れる。
直近の回答を1つ検索すれば、回答数を取得できる。

という感じで、DBの設計でどうにでもなります。
将来的に何がしたいか、何はしなくていいかを考えないと
設計できませんが。

Answer 4

100回に1回しか有効でない判定を毎回行うのが無駄で嫌だと思うのであれば、Cron等で毎日1回(毎時1回でも)とかでバッチ処理を走らせる方法もあります。
こうすると全ユーザーの回答数を一気に確認する事が出来て、無駄が少なくなります。
欠点としては、リアルタイムなチェックができにくい事ですね。