What's changed: Created DP-420 Chapter 4 (Domain 4: query optimization and indexing (indexing policy included/excluded paths, write-heavy vs read-heavy, composite index, range/spatial, integrated cache via dedicated gateway, RU cost via request charge/query metrics); change feed (Azure Functions trigger/SDK change feed processor with lease/change feed estimator backlog/denormalize update-referential enforcement-aggregation persistence-archiving)).
4.2Working with the change feed
Understand processing the change feed (Azure Functions trigger, SDK change feed processor), the change feed estimator, and denormalization/referential enforcement/aggregation persistence/archiving via the change feed.
The change feed is a durable, time-ordered read of item creates/updates in a container—the foundation of event-driven pipelines (from an optimization view, it offloads heavy synchronous work to async).
4.2.1Ways to process the change feed
Two main ways: an Azure Functions Cosmos DB trigger processes changes serverlessly (easy ops, Functions handles scale), or the SDK change feed processor embeds in the app, consuming in parallel with checkpoints in a lease container (fine-grained control). For scaling, the change feed estimator gauges the unprocessed change backlog, informing decisions to scale processing instances (parallelism) up or down.
4.2.2Change feed use cases
Common patterns with the change feed: updating denormalized copies (when the source changes, update copies), enforcing referential integrity (keep related items consistent), persisting aggregations (instead of aggregating at read time, update aggregate results on change to speed reports), and archiving data (move old changes to another store). All optimize read RU/latency by "pre-processing on write via the change feed" instead of "heavy compute at read time."
Continue reading — free sign-up
You're reading the free preview. Sign up free to read this section in full, plus every chapter (including 4+) and all questions.