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."
Cues: "process changes serverlessly" = Azure Functions Cosmos DB trigger. "fine control / parallel consume in-app" = SDK change feed processor (lease container). "scale instances by unprocessed backlog" = change feed estimator. "pre-compute heavy read-time aggregation on write" = aggregation persistence.
Watch the mix-ups: (1) Change feed processor (consume) vs change feed estimator (gauge backlog). (2) The change feed returns creates/updates; by default deletes are not included (model deletes via TTL + soft-delete). (3) The Functions trigger and the SDK processor are different ways to consume the same change feed.
4.2.3Section summary
- Process the change feed = Azure Functions trigger (serverless) or SDK change feed processor (parallel via lease)
- The change feed estimator gauges the unprocessed backlog to scale processing instances
- Use cases = denormalize update/referential enforcement/aggregation persistence/archiving to optimize reads
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. You want to process container changes serverlessly with minimal infrastructure management. Best?
Q2. You want to consume the change feed in parallel in-app with checkpoints via leases and fine control. Best?
Q3. You want to gauge the unprocessed change-feed backlog to scale processing instances. Best?
Q4. For reporting, you want to avoid heavy read-time aggregation by updating aggregate results on change. Best pattern?
Q5. Which is correct about the default change feed?
Keep track of your progress
The full study guide is free to read. Sign up free to practice with the question bank, track what you have read, review your mistakes, and highlight passages.