An ordinance assistant already knows the id and partition key of a chunk it must load, while admins sometimes run ad hoc cross-partition searches. Which access pattern should the service prefer for the known chunk?
Select an answer to reveal the explanation.
Short Explanation
If you already have the street address and unit number, don’t search the whole city—point-read the ordinance chunk by id and partition key, and save the big hunts for admin tools.
Full Explanation
When an ordinance assistant already knows the id and partition key of a chunk, a Cosmos DB point read is the efficient access pattern: it targets a single logical partition and item with predictable, low RU cost. Cross-partition queries remain appropriate for ad hoc admin tools that must explore without keys, but the service path for known chunks should prefer point reads. That split keeps municipal AI hot paths cheap and reserves expensive fan-out queries for intentional exploration.
Always running a cross-partition query even when id and partition key are known wastes RUs and adds latency for no functional gain. Downloading the entire container to the client for every ordinance lookup does not scale and moves filtering out of the data service. Replacing point reads with unindexed ORDER BY scans across all partitions maximizes RU burn and is the opposite of known-key retrieval.
Exam caveat: point reads require both id and the correct partition-key value; a wrong partition key yields not-found even if the id exists elsewhere—design municipal item models so AI services persist both keys with citations. Operational check: instrument the ordinance path to count point reads versus cross-partition queries, assert hot-path lookups use point reads, and sample RU charges per known-chunk load against a cross-partition baseline to prove the savings.