Examkin

Question

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

You are designing an Azure Cosmos DB Core (SQL) API container for a logistics monitoring system that tracks delivery fleet telemetry. The system receives data from 50,00050,000 active vehicles. Each vehicle is assigned to one of 2020 shipping carriers.

The telemetry documents contain the following fields:
- `vehicleId` (unique string identifier)
- `carrierId` (unique carrier code)
- `routeId` (unique route identifier)
- `timestamp` (date and time of the reading)
- `location` (latitude/longitude coordinates)

The system has the following requirements:
- Writes: Telemetry is ingested continuously at a rate of 5,0005,000 writes per second. Three large shipping carriers account for 85%85\% of all vehicle updates.
- Reads: Active tracking dashboards query vehicle locations for a specific route. These queries always filter by `routeId` and `timestamp`.
- Transactions: When a vehicle crosses a state line, the platform must execute a transactional batch operation to atomically update the vehicle status and insert a route checkpoint log.

Which partition key strategy should you select to meet these requirements while preventing hot partitions and optimizing query performance?

  1. A
    Configure `vehicleId` as the partition key to maximize write distribution across all physical partitions.
  2. B
    Configure `carrierId` as the partition key to group all telemetry for each shipping company together.
  3. Create a synthetic partition key that combines `routeId` and the date portion of the `timestamp` (for example, `routeId_date`).Answer
  4. D
    Configure `vehicleId` as the partition key, and rely on Session consistency to guarantee transactional atomicity for the route checkpoint updates.

Answer

Create a synthetic partition key that combines routeId and the date portion of timestamp.
The correct answer is correct because creating a synthetic partition key combining the route identifier and the date allows the container to distribute data across multiple partitions over time, avoiding the hot partition issue of using a low-cardinality key like carrier identifier or an unboundedly growing partition like route identifier alone. Furthermore, since transactions are scoped to a route on a specific day, grouping them under the same synthetic partition key satisfies the Cosmos DB constraint that all items in a TransactionalBatch must share the same partition key value.

Step-by-Step Solution

1
Identify the transactional boundaries of the application.
Recognize that TransactionalBatch requires all participating documents to share the same partition key value.
Cosmos DB transactions are restricted to a single logical partition.
2
Analyze the write throughput skew and cardinality to avoid hot partitions.
Determine that using carrierId (low cardinality, high skew) or routeId alone (unbounded growth over time) will create hot partitions.
A partition key must distribute RU consumption and storage evenly across logical and physical partitions.
3
Combine the transactional scope with the query and partitioning requirements using a synthetic key.
Derive a synthetic key routeId_date (e.g., route_1092_2026-07-16).
This satisfies the transaction scope for a single route on a given day, avoids unbounded partition growth, and supports single-partition read queries.

Key Concept

Synthetic Partition Keys and Transactional Boundaries in Azure Cosmos DB

Alternative Method

An alternative approach is to use a hierarchical partition key (available in newer Cosmos DB versions) with `routeId` as the first level and `date` as the second level, which achieves a similar logical structure without manually concatenating strings in client code.
Estimated Time:2m 30s
Rate this question

Topics

Configure Partition Keys and Partitioning Strategies in Azure Cosmos DB

More questions from this topic