【要約】ページは先に進めるのに、totalだけ足りなかった話 [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
開発者が、ログインユーザー向けフィードの合計件数が、未ログイン時よりも少なく表示される現象に直面した。ログインユーザーにはスコアリング機能を提供しており、以下の設計上の不整合が原因であった。
- ・計算量削減のため、スコアリング対象を直近100件（FEED_SCORING_POOL_SIZE）に制限した。
- ・ページ送り自体は、取得済みID（exclude_ids）を用いて制限を超えて進める設計であった。
- ・しかし、合計件数（total）を、制限後の配列長（len(candidates)）から算出していた。
- ・その結果、ページ送りは可能だが、表示上の総件数が100件で頭打ちになる矛盾が生じた。
// Approach
開発者は、合計件数の算出ロジックを、内部的な取得制限から完全に切り離す手法を採用した。計算コストを抑えるための制約が、ユーザーへの情報表示を歪めないように設計を修正した。
- ・合計件数（total）の算出に、絞り込み後の配列ではなく、フィルタ条件を適用したクエリへのcount()を実行した。
- ・スコアリング用の取得制限（limit）は、表示用のデータ取得プロセスにのみ適用した。
- ・「表示用のデータ取得」と「正確な件数の算出」という、異なる目的の処理を分離した。
// Result
開発者は、ログイン状態に関わらず、フィルタ条件に基づいた正確な記事総件数を表示することに成功した。これにより、ユーザー体験の向上と設計の堅牢性を両立させた。
- ・未ログイン時と同様の、正確なCOUNT結果を返却できるようになった。
- ・内部的なスコアリング用制限（100件）を変更しても、totalの正確性に影響しない設計となった。
- ・コードパスごとに、変数の使い回しによる副作用がないことを確認した。
Senior Engineer Insight
> 典型的な「責務の混同」によるバグである。計算コスト削減のための制約（Limit）を、メタ情報（Total）の算出に流用したことが致命的だった。大規模システムでは、COUNTクエリの負荷が無視できないため、正確性とパフォーマンスのトレードオフを常に意識すべきだ。また、ログイン/未ログインのようにロジックが分岐する場合、片方の実装の都合がもう片方に悪影響を及ぼしていないか、パスごとに厳格な検証が求められる。