Question

Difficulty: Very hardHigh-Performing Database Solutions

A real-time bidding application uses Amazon DynamoDB to track active auctions. During peak bidding hours, the write volume spikes to 120,000120,000 writes per second, causing some write requests to fail with `ProvisionedThroughputExceededException` errors, even though the total provisioned write capacity is sufficient for the workload. Additionally, the application requires microsecond-latency reads to retrieve auction details, and concurrent analytics queries are degrading the write performance of active auctions.

Which two actions should the solutions architect take to resolve these performance issues? (Select TWO.)

  1. Deploy an Amazon DynamoDB Accelerator (DAX) cluster to handle read requests for auction details with microsecond latency.Answer
  2. Redesign the partition key schema by appending a random suffix to the auction ID to distribute write requests evenly across partitions.Answer
  3. C
    Configure RDS Read Replicas for the DynamoDB table and use them as automatic failover endpoints to maintain write capacity during spikes.
  4. D
    Redesign the DynamoDB table to use the auction start timestamp as a monotonically increasing partition key to simplify sequential querying.
  5. E
    Switch the DynamoDB table to provisioned capacity mode with a fixed partition key based on the auction category to group all bids together.

Answer

Deploying an Amazon DynamoDB Accelerator (DAX) cluster to handle read requests and redesigning the partition key schema by appending a random suffix to the auction ID.
The correct response involves deploying an Amazon DynamoDB Accelerator (DAX) cluster to cache read requests, reducing read latency to microseconds and offloading read traffic from the table to prevent read contention. It also requires redesigning the partition key schema to append a random suffix to the partition keys, which implements write sharding and distributes the highly concentrated write load across multiple partition keys, thereby preventing write bottlenecks on a single hot partition.

Step-by-Step Solution

1
Analyze the database performance bottleneck under the high write volume of 120,000120,000 writes per second.
Identify that the throttling errors, despite sufficient total provisioned capacity, are caused by uneven access patterns resulting in one or more hot partitions.
DynamoDB distributes data across partitions based on the partition key value, so sequential or concentrated keys overload individual partitions.
2
Determine the correct strategy to mitigate hot partition keys and distribute write operations.
Select the option to append a randomized suffix (sharding) to the partition key (auction ID).
This distributes the writes for the same auction across multiple physical partitions, utilizing the provisioned throughput of the entire table.
3
Analyze the read performance requirement of microsecond-level latency and read contention from reporting queries.
Select Amazon DynamoDB Accelerator (DAX) to serve reads directly from an in-memory cache.
DAX provides microsecond latency for cached reads and offloads read requests from the DynamoDB table, preventing read contention from degrading write performance.

Key Concept

Mitigating DynamoDB partition write bottlenecks (hot keys) and improving read latency using in-memory caching (DAX).
Rate this question