关于Cosmos DB Change Feed时间分辨率与高频更新事件触发机制的技术问询
Let’s break down your Cosmos DB Change Feed questions clearly:
1. What’s the time resolution of Cosmos DB Change Feed?
The time resolution ties directly to Cosmos DB’s logical timestamp (_ts property), which is accurate to the second. That said, the actual perceived resolution depends on how you’re consuming the feed. By default, the Change Feed Processor uses a 5-second polling interval (configurable via FeedPollDelay), but if your container has steady write traffic, events are pushed more promptly. To sum up: the theoretical precision is second-level, while real-world latency depends on your processor configuration and container load.
2. Handling multiple updates to the same document
First off, your understanding is 100% correct. Cosmos DB Change Feed is designed to return the final state of a document, not every individual write. When the same document gets updated in rapid succession, the feed will merge those updates and only send the latest version—this is an optimization to reduce redundant events and improve performance, since most use cases only care about the end state.
Typical minimum interval for separate events
From practical experience, you’ll usually need a second-level gap (roughly 1-5 seconds) between two updates to ensure each triggers a separate event in the Change Feed. Keep in mind this isn’t a hard number—factors like:
- High write load on the container (busier containers may have slightly longer merge windows)
- Your Change Feed Processor’s polling interval (shorter polls make it easier to catch close-together updates)
- Cross-region replication delays (if writing across regions, latency can affect event timing)
can all shift this slightly.
Service Level Agreement (SLA) for this interval
There’s no formal SLA for this minimum interval. The merge behavior is an intentional optimization of the Change Feed, not a guaranteed feature. Official documentation explicitly states that the feed doesn’t promise an event for every single write—only that it will return the final state of documents up to a certain point. If your use case requires capturing every individual write, the Change Feed might not be the best fit. You could instead log each write to a separate "audit" container, or explore Azure Event Grid’s Cosmos DB trigger (though note Event Grid also has similar merging behavior, just with different thresholds).
内容的提问来源于stack exchange，提问作者Mo B.
