A logistics company operates an IoT fleet monitoring dashboard. Telemetry data from devices is continuously written to an Amazon DynamoDB table. The table's partition key is `device_type` (which has three distinct values) and its sort key is `timestamp`. During peak periods, the application receives a high volume of writes and experiences `ProvisionedThroughputExceededException` errors. To resolve this, a developer deploys an Amazon DynamoDB Accelerator (DAX) cluster in front of the table and updates the application to write through the DAX client. However, the write throttling errors persist. Which of the following explains why the write throttling continues and provides the correct resolution?
- AThe DAX cluster size is too small to handle the write volume. The developer should scale the DAX cluster horizontally by adding more read replicas to distribute the write traffic.
- BThe dashboard application is executing Scan operations to locate the devices before performing updates. The developer should replace these Scan operations with Query operations to resolve the throttling.
- DAX is a write-through cache and does not shield the DynamoDB table from write throttling. The developer must redesign the table schema to use a high-cardinality partition key like `device_id`.Answer
- DThe developer should deploy an Amazon ElastiCache for Memcached cluster to cache the write operations, as ElastiCache scales write throughput horizontally across multiple nodes.
Answer
DAX is a write-through cache and does not shield the DynamoDB table from write throttling. The developer must redesign the table schema to use a high-cardinality partition key like `device_id` to distribute writes evenly across partitions.
The correct choice explains that Amazon DynamoDB Accelerator (DAX) is a write-through cache, meaning write requests are forwarded directly to the backend DynamoDB table. Deploying DAX does not prevent write throttling on the underlying database. The write throttling is caused by a hot partition key because the partition key (`device_type`) has low cardinality (only three values). Changing the partition key to a high-cardinality attribute like `device_id` ensures that writes are distributed across multiple partitions.
Step-by-Step Solution
Key Concept
Amazon DynamoDB Accelerator (DAX) is a write-through cache, meaning write requests are forwarded directly to the backend DynamoDB table. It does not queue or buffer write operations to protect DynamoDB from write capacity exhaustion or hot partitions. Redesigning the schema with a high-cardinality partition key is necessary to address write hot partitions.