Question

Difficulty: HardConfigure Partition Keys and Partitioning Strategies in Azure Cosmos DB

You are designing an Azure Cosmos DB Core (SQL) API solution for a smart city traffic management platform. The platform collects real-time vehicle telemetry from 10,00010,000 traffic sensors deployed across 55 major cities.

Workload Profiles:
- Write Ingestion: Highly write-heavy. Each sensor transmits telemetry (including `sensorId`, `cityName`, `timestamp` in `YYYY-MM-DD hh:mm:ss` format, and `vehicleCount`) every 1010 seconds. Write volume peaks heavily during rush hours.
- Read Queries: Real-time traffic control dashboards query the most recent 55 minutes of telemetry data for a specific city to adjust traffic light timings (high-frequency, low-latency reads).
- Transactional Boundary: A stored procedure must run atomically to update both the daily aggregate vehicle count and the latest telemetry record for a specific sensor.

You need to select the partitioning strategy that avoids the hot partition problem for writes, satisfies the transactional requirements, and minimizes Request Unit (RU) consumption for read queries.

Which two strategies should you implement? (Select two.)

  1. Define a synthetic partition key for the primary container by concatenating the sensorId and the date portion of the timestamp (e.g., sensorId_YYYY-MM-DD).Answer
  2. Use the Azure Cosmos DB Change Feed to replicate telemetry data to a secondary container partitioned by cityName to serve the dashboard queries.Answer
  3. C
    Define the partition key as cityName on the primary container.
  4. D
    Use the date portion of the timestamp (e.g., YYYY-MM-DD) as the partition key for the primary container.
  5. E
    Define the partition key as sensorId on the primary container and execute multi-partition transactions to update daily aggregates.

Answer

The correct strategies are defining a synthetic partition key by concatenating the sensorId and the date portion of the timestamp, and using the Azure Cosmos DB Change Feed to replicate telemetry data to a secondary container partitioned by cityName.
Defining a synthetic partition key by concatenating the sensorId and the date portion of the timestamp ensures that write volume is evenly distributed across a high number of logical partitions, avoiding the hot partition problem. This partition key also scopes daily sensor transactions within a single logical partition, allowing successful execution of atomic stored procedures. Using the Azure Cosmos DB Change Feed to replicate telemetry data to a secondary container partitioned by cityName allows dashboard queries to be processed as efficient single-partition reads, avoiding expensive cross-partition scans.

Step-by-Step Solution

1
Analyze write ingestion patterns and hot partition risks.
Using cityName or YYYY-MM-DD on the primary container results in hot partitions because writes are concentrated in a few cities during rush hour or on a single daily partition.
Choosing a high-cardinality key is essential to distribute write throughput across multiple physical partitions.
2
Evaluate transactional boundaries.
Since transactions (stored procedures) require atomic updates on both the daily aggregate and the latest telemetry for a specific sensor, the partition key must encompass the sensor ID and the specific day.
Cosmos DB transactions are strictly scoped to a single logical partition.
3
Analyze read query efficiency and optimize container layout.
Dashboard queries filter by cityName, which would result in expensive cross-partition queries on a container partitioned by sensorId. Replicating the data to a secondary container partitioned by cityName via the Change Feed solves this.
Replication enables fast single-partition reads for dashboard queries without compromising the write performance of the primary ingestion container.

Key Concept

Selecting a partition key involves balancing write distribution (preventing hot partitions), transactional scopes (single-partition boundaries), and read optimization (minimizing cross-partition queries).
Rate this question