You are designing an Azure Cosmos DB Core (SQL) API container for an IoT smart grid monito… — Microsoft Azure Developer (AZ-204)

You are designing an Azure Cosmos DB Core (SQL) API container for an IoT smart grid monitoring system. The system receives telemetry from $10$ electrical substations (`substationId`). Substation 1 is a major hub that handles $90\%$ of the grid's power transmission and has $1,000,000$ active smart sensors reporting status updates. The other $9$ substations have only $1,000$ sensors each. During peak periods, the container must ingest up to $100,000$ writes per second.

The system has the following requirements:
* Transactional Boundary: For every sensor update, the system must write both a telemetry status document and an associated alarm log document (if a threshold is exceeded) in a single transactional batch. These two documents share the same `sensorId` and `substationId` values.
* Query Profile: The primary read workload consists of real-time control room dashboard queries that retrieve and aggregate telemetry for a specific `substationId` over a rolling $5$ -minute window.

Which partitioning strategy should you implement to meet these requirements while avoiding hot partitions?

A
Use the `substationId` property directly as the partition key.
B
Use the `sensorId` property directly as the partition key.
C
Use a synthetic partition key combining `substationId` and a random integer suffix generated at runtime (e.g., `substationId_randomSuffix`).
Use a synthetic partition key combining `substationId` and a deterministic hash of the `sensorId` (e.g., `substationId_hashSuffix`).Answer

Answer

Use a synthetic partition key combining the substation ID and a deterministic hash of the sensor ID.

The correct strategy is to use a synthetic key combining the substation ID with a deterministic hash of the sensor ID. This distributes the massive write load of Substation 1 across a configured number of buckets (e.g., 100 partitions), preventing physical partition write limits from being exceeded. Because the hash is deterministic based on the sensor ID, the telemetry status document and the alarm log document for any given sensor will always resolve to the exact same partition key, preserving the transaction boundary required for transactional batch writes. Additionally, queries filtered by substation ID only need to scan the designated 100 partitions rather than performing a full cross-partition search across the entire database.

Step-by-Step Solution

Analyze the write workload and identify the hot partition risk.

Substation 1 handles

90\%

of the ingestion load. Partitioning directly by `substationId` will target a single partition for nearly all writes, exceeding the

10,000\text{ RU/s}

and

20\text{ GB}

physical partition limits.

We must distribute the writes for Substation 1 to prevent throttling and storage limits.

Evaluate the transactional boundary constraint.

Cosmos DB transactional batches require all items in the transaction to share the exact same partition key.

Since the status and alarm logs must be written transactionally for a sensor, they must share the same partition key value.

Evaluate the read query profile.

Queries target a specific `substationId`. If we partition by `sensorId`, queries by `substationId` must fan out to all physical partitions (millions of sensors), which is highly inefficient.

The partition key must allow routing queries to a small, predictable number of partitions.

Synthesize the optimal partition key solution.

A synthetic key combining `substationId` and a deterministic hash of `sensorId` (e.g., `substationId` + `(sensorId % 100)`) splits Substation 1 into

100

logical partitions to avoid write hotspots. It keeps documents for the same sensor in the same partition for transactional batch operations, and limits read queries to fan out to only

100

partitions rather than millions.

This strategy balances write distribution, transactional integrity, and query performance.

Key Concept

Selecting and configuring synthetic partition keys in Azure Cosmos DB to balance write ingestion distribution, transactional scope, and read query efficiency.

Estimated Time:3m 0s

Question

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Topics

More questions from this topic