Question

Difficulty: HardHigh-Performing Database Solutions

A logistics company is designing an asset tracking system to ingest real-time location telemetry from a fleet of 50,00050,000 delivery vehicles. The system must support a write volume that is highly unpredictable and spiky, peaking at 20,00020,000 writes per second. Each telemetry message contains a timestamp, a unique vehicle identifier, and coordinate data. Lookups for the latest vehicle locations must achieve sub-millisecond latency. Which database design and configuration meets these performance requirements?

  1. A
    Deploy an Amazon RDS for PostgreSQL database in a Multi-AZ deployment. Configure multiple Read Replicas, and route write operations to the Read Replicas to distribute the write load and achieve sub-millisecond write latency.
  2. Configure an Amazon DynamoDB table in On-Demand capacity mode using a partition key that combines the vehicle identifier and a date string (e.g., `VehicleID_YYYY-MM-DD`). Enable Amazon DynamoDB Accelerator (DAX) to cache read queries.Answer
  3. C
    Configure an Amazon DynamoDB table in On-Demand capacity mode using a partition key consisting of a monotonically increasing timestamp. Enable Amazon DynamoDB Accelerator (DAX) to cache read queries.
  4. D
    Configure an Amazon DynamoDB table in Provisioned Capacity mode using a partition key that combines the vehicle identifier and a date string (e.g., `VehicleID_YYYY-MM-DD`). Rely on DynamoDB Auto Scaling to scale write capacity to meet the sudden, unpredictable spikes in write traffic.

Answer

Configure an Amazon DynamoDB table in On-Demand capacity mode using a partition key that combines the vehicle identifier and a date string (e.g., `VehicleID_YYYY-MM-DD`), and enable Amazon DynamoDB Accelerator (DAX) to cache read queries.
The correct answer combines a high-cardinality partition key (`VehicleID_YYYY-MM-DD`) to distribute write operations evenly across partitions, DynamoDB On-Demand capacity mode to automatically and instantly scale to accommodate sudden and unpredictable write spikes, and Amazon DynamoDB Accelerator (DAX) to provide the required sub-millisecond read latency.

Step-by-Step Solution

1
Analyze the workload characteristics, specifically the highly unpredictable and spiky write traffic peaking at 20,00020,000 writes per second, and the need for sub-millisecond read latency.
Identify that the database must scale instantly to handle write spikes without throttling, and requires an in-memory caching layer for sub-millisecond reads.
Traditional provisioned database resources or standard RDS clusters cannot scale instantly or provide sub-millisecond read latencies without caching.
2
Determine the optimal database partition key design to prevent hot partitions.
Select a high-cardinality partition key like a combination of `VehicleID` and a date string (`VehicleID_YYYY-MM-DD`) instead of a sequential timestamp or static date.
Distributing the writes across partitions prevents write throttling on a single partition.
3
Determine the database capacity mode and read caching mechanism.
Select DynamoDB On-Demand capacity mode to handle unpredictable write traffic spikes, and deploy DynamoDB Accelerator (DAX) for sub-millisecond read caching.
On-Demand mode accommodates sudden traffic spikes immediately, and DAX delivers microsecond read response times.

Key Concept

Designing high-performing, scalable DynamoDB tables with appropriate partition keys, capacity modes, and caching to avoid bottlenecks and deliver low latency.
Rate this question