変更要約: DP-420 第4章を新規作成（ドメイン4: クエリ最適化とインデックス(インデックスポリシー included/excluded path・書き込み多 vs 読み取り多・複合インデックス・range/spatial・統合キャッシュ integrated cache 専用ゲートウェイ・RU コスト request charge/クエリメトリクス)、変更フィード(Azure Functions トリガー/SDK change feed processor・lease/変更フィードエスティメーター backlog/非正規化更新・参照強制・集計永続化・アーカイブ)）。
4.2変更フィード（change feed）の活用
変更フィードの処理（Azure Functions トリガー、SDK の change feed processor）、変更フィードエスティメーター、変更フィードによる非正規化/参照強制/集計永続化/アーカイブを理解します。
変更フィード（change feed） はコンテナの項目の作成/更新を時系列で永続的に読み取れる仕組みで、イベント駆動の処理パイプラインの土台になります（最適化の観点では「重い同期処理を非同期に逃がす」役割）。
4.2.1変更フィードの処理方法
処理方法は主に 2 つ＝Azure Functions の Cosmos DB トリガー でサーバーレスに変更を受けて処理する（運用が簡単・スケールは Functions 任せ）、または SDK の change feed processor でアプリ内に組み込み、リース（lease）コンテナでチェックポイントしながら並列に消費する（細かい制御が可能）。スケールでは 変更フィードエスティメーター（change feed estimator） が 未処理の変更量（バックログ） を見積もり、処理インスタンス数（並列度）を増減する判断に使う。
4.2.2変更フィードの用途
変更フィードを使った定番パターン＝非正規化した複製の更新（元が変わったら複製先も更新）、参照整合性の強制（関連項目の整合維持）、集計の永続化（実行時に集計せず、変更時に集計結果を更新しておきレポートを高速化）、データのアーカイブ（古い変更を別ストアへ退避）。いずれも「読み取り時に重い計算をする」代わりに「書き込み時に変更フィードで前処理する」ことで、読み取りの RU/遅延を最適化する考え方です。