AZ-305 Practice Question 34: Telemetry Partition Strategy
Microsoft Azure Solutions Architect Expert (AZ-305) · Test 4 · question 4 of 10
A utility stores smart meter readings in an Azure Cosmos DB for NoSQL container. There are 40,000 meters in four regions, the container already holds 5 TB, and it grows continuously. Nearly every query filters on a single meter ID and a date range. Analysis of the data shows that a few hundred industrial meters each produce enough readings to exceed 20 GB on their own, while most meters produce a fraction of that.
Which partitioning strategy should the design use?
Show answer and explanation
Answer:
Two constraints decide this. Every logical partition is capped at 20 GB, and the industrial meters would blow through that cap if meterId alone were the key. At the same time, the queries filter on meter ID, so the key must align with that predicate or every read becomes a cross-partition query. Hierarchical partition keys resolve the tension: Microsoft documents them as the way to avoid the 20 GB limit by creating multiple levels of partitioning, while still routing efficiently for queries that filter on the first level, or on the first and second levels together, which is exactly a meter ID plus a date range.
Option A has far too little cardinality. Four regions means four logical partitions, each one far past 20 GB and all of the traffic for a region funnelled through a single partition, the textbook hot-partition anti-pattern.
Option B distributes storage better but concentrates load in the worst possible way: all writes for a given day land in one logical partition, so the container's hottest partition is always today. Queries for one meter across a month must also fan out across every day's partition.
Option C is the most plausible wrong answer. Using /id gives perfect write distribution and cheap point reads, which is why it is a good key for point-read-heavy workloads. But it makes every item its own logical partition, and any query that filters on something other than id (here, always meterId and a time range) becomes a cross-partition query, growing more expensive as the container adds physical partitions.
Reference: Partitioning and horizontal scaling in Azure Cosmos DB