Question

Difficulty: HardHigh-Performing Database Solutions

A logistics company is designing an IoT fleet management platform for 150,000150,000 delivery vehicles. Each vehicle transmits telemetry data every 1010 seconds. The storage layer must support write ingestion at scale and enable real-time queries for vehicle locations with sub-millisecond read latency. While the write traffic is evenly distributed across the fleet, read requests are highly concentrated: a small subset of high-priority delivery vehicles (representing less than 1%1\% of the active fleet) is queried hundreds of times per second for live tracking dashboards. Which database design meets these performance requirements while optimizing costs?

  1. A
    Amazon RDS for PostgreSQL configured with a Multi-AZ deployment and a Read Replica, routing all read queries to the Read Replica and promoting the Read Replica to the primary DB instance if write latency spikes.
  2. B
    Amazon DynamoDB with a partition key of `timestamp` and a sort key of `vehicle_id`, fronted by Amazon DynamoDB Accelerator (DAX) to cache read requests.
  3. Amazon DynamoDB with a partition key of `vehicle_id` and a sort key of `timestamp`, fronted by Amazon DynamoDB Accelerator (DAX) to cache read queries for the high-priority vehicles.Answer
  4. D
    Amazon DynamoDB with a partition key of `vehicle_id` and a sort key of `timestamp`, using DynamoDB Auto Scaling in provisioned capacity mode with local secondary indexes (LSIs) to handle the read spikes.

Answer

Amazon DynamoDB with a partition key of vehicle_id and a sort key of timestamp, fronted by Amazon DynamoDB Accelerator (DAX) to cache read queries for the high-priority vehicles.
The correct database design uses Amazon DynamoDB with a partition key of vehicle_id, which provides high cardinality and evenly distributes write requests across partitions. Fronting the table with Amazon DynamoDB Accelerator (DAX) caches read requests for the hot vehicle IDs, delivering sub-millisecond read latency for the live dashboards and preventing partition read throttling in a cost-effective manner.

Step-by-Step Solution

1
Analyze the ingestion and query patterns of the vehicle fleet telemetry workload.
Identify that the system requires high-throughput write scaling and sub-millisecond read latency for a small, heavily-queried set of hot keys (the high-priority vehicles).
This establishes that a caching layer is necessary to achieve sub-millisecond read latencies and offload hot partitions.
2
Select a partition key schema that ensures uniform write distribution across partitions.
Choose vehicle_id as the partition key instead of a sequential timestamp.
Using vehicle_id distributes the write payload across partitions, preventing a hot partition write bottleneck.
3
Select a caching strategy to handle read hot keys and deliver sub-millisecond latency.
Configure Amazon DynamoDB Accelerator (DAX) in front of the DynamoDB table.
DAX provides microsecond response times for cached reads and prevents read operations on high-priority vehicles from exhausting the table's read capacity.

Key Concept

High-Performance DynamoDB design using high-cardinality partition keys and DynamoDB Accelerator (DAX) to resolve read hotspots.
Rate this question