cosmos change feed
What it is
The Azure Cosmos DB change feed is a persistent record of changes to a container. A consumer reads changes asynchronously and incrementally, so a data update can start follow-up work without making the original write wait.
Think of the update ledger at a warehouse. Each aisle keeps its own ordered list of stock changes. Several teams can read the lists, but a team must remember how far it got before leaving.
Why it exists
Northwind should save an order first, then let other systems react: create an analytics record, update a search index, or notify the warehouse. The change feed separates those reactions from the original database write.
Key ideas
- The feed records changes to items in a Cosmos DB container. It can be processed by Azure Functions, a change-feed processor, a pull model, or other supported consumers.
- Consumers use a checkpoint or continuation position to resume after a restart. The change-feed processor manages checkpoints and offers at-least-once processing, so a consumer must handle repeats safely.
- Changes are ordered by modification time within a partition key. There is no guaranteed order across different partition-key values.
- In latest-version mode, consumers see the latest insert or update for an item; it does not identify insert versus update and does not capture deletes. All versions and deletes mode records creates, updates, and deletes, but requires continuous backup and is limited to that backup period.
- More than one consumer can process the same container. Parallel processing follows partition key ranges rather than a single global sequence.
Northwind example
When Northwind writes an order update to its Cosmos DB container, a change-feed processor receives it. It updates the reporting system using the order ID as an idempotency key. If the processor crashes after updating reports but before checkpointing, it can receive the change again; the same key makes the second attempt harmless. A separate consumer can update customer recommendations without competing for the report consumer’s progress.
Change feed versus Event Grid and Event Hubs
| Need | Start by considering |
|---|---|
| React to mutations stored in a Cosmos DB container | Cosmos DB change feed |
| Route a discrete notification from many Azure or custom sources | [[event-grid |
| Ingest a high-volume, time-retained telemetry stream | [[event-hubs |
The change feed is tied to data changes in one Cosmos DB container. It does not replace a general-purpose message broker or event-routing service.
Common confusion
- The change feed is not a transaction log that makes every downstream system automatically consistent with Cosmos DB.
- A consumer reading a change must still handle its own errors, retries, permissions, and duplicate business effects.
- “Ordered” does not mean globally ordered. Include the partition-key boundary in any ordering requirement.
Related
cosmos-db · cosmos-consistency · azure-functions · event-grid · event-hubs · northwind-traders-case-study
Sources and re-audit
- Microsoft Learn — Change feed in Azure Cosmos DB, checked 2026-09-16.