A kelp-drying loft scales three change feed processor workers against one large Cosmos container. How should work be distributed?
Select an answer to reveal the explanation.
Short Explanation
Think of partition-key ranges as checkout lanes—the processor assigns lanes to workers. Order holds per partition key, not as one global line for the whole container. Skip inventing your own mutex.
Full Explanation
When a kelp-drying loft scales three change feed processor workers against one large Cosmos container, work should be distributed by partition-key range (feed range). The processor assigns feed ranges to workers and coordinates ownership through the lease store so scale-out is safe. Ordering is preserved per partition key, which matches how Cosmos physical partitions and the change feed are sliced.
Writing a custom mutex in Blob Storage so only one worker may run serializes the loft and throws away the processor’s built-in parallelism. Guaranteeing a single global order across all partition keys is not what the change feed processor provides and is not required for correct per-key processing. Pinning all three workers to the same lease document forces contention and serial processing, defeating scale-out.
Exam caveat: per-partition-key order is not global container order. If a downstream kelp workflow needs a total order across keys, that must be imposed in application design, not assumed from the feed.
Operational check: run three processor instances with a shared lease container, inspect lease ownership across feed ranges, and confirm each range is processed by one owner at a time while overall throughput rises versus a single worker.