Examkin

Question

Difficulty: MediumAzure Cosmos DB and NoSQL Solutions

An online food delivery service is designing a real-time driver tracking system on Azure. The system will ingest GPS coordinates every 5 seconds from 50,000 drivers. The solution must support sub-10ms write latency, distribute write operations evenly to prevent performance degradation, and remain available in the event of a regional datacenter outage. The primary query will retrieve the latest coordinates for a specific active trip using its unique trip identifier (a high-cardinality GUID). Which configuration should you recommend?

  1. Set the partition key to the trip identifier and enable multi-region writes for the Azure Cosmos DB account.Answer
  2. B
    Set the partition key to the vehicle type and enable multi-region writes for the Azure Cosmos DB account.
  3. C
    Set the partition key to the trip identifier and configure the account as a single-region deployment using Locally Redundant Storage (LRS).
  4. D
    Set the partition key to the trip identifier, enable multi-region writes, and use an embedded 3-year Shared Access Signature (SAS) token in the client for direct archival to Azure Blob Storage.

Answer

Set the partition key to the trip identifier and enable multi-region writes for the Azure Cosmos DB account.
The correct design uses the high-cardinality trip identifier (GUID) as the partition key to distribute write workloads evenly across partitions, combined with multi-region writes to satisfy the sub-10ms write latency and regional disaster resilience requirements.

Step-by-Step Solution

1
Evaluate the partition key cardinality to prevent hot partitions under high write load.
The trip identifier (GUID) is high-cardinality, ensuring uniform distribution of write and read requests across logical partitions.
Using low-cardinality keys like vehicle type concentrates writes on few partition keys, leading to partition key exhaustion and throughput throttling.
2
Select the replication and redundancy strategy to survive regional outages and meet latency requirements.
Configure multi-region writes.
Multi-region writes allow local writes in multiple regions with low latency, providing high availability and regional failover capabilities, whereas LRS lacks regional redundancy.
3
Evaluate secure data access for external storage/archival needs.
Avoid long-lived, direct SAS tokens embedded in the client.
Long-lived SAS tokens without stored access policies cannot be revoked easily and represent a major security risk.

Key Concept

Designing partition keys for even throughput distribution and multi-region replication for disaster recovery in Azure Cosmos DB.
Rate this question

Topics

Azure Cosmos DB and NoSQL Solutions

More questions from this topic