Examkin

Question

Difficulty: Very hardHigh-Performing Database Solutions

A financial technology company runs a real-time ledger application that processes high-frequency ledger entries. The transaction volume peaks at 25,00025,000 write operations per second. The application uses an Amazon DynamoDB table with a partition key of `AccountID` (UUID) and a sort key of `TransactionTimestamp`. During peak trading hours, transactions for a few high-volume institutional accounts are throttled with `ProvisionedThroughputExceededException` errors, even though the table's total read and write capacities are scaled using on-demand mode. The application requires consistent sub-second write response times and must retrieve transactions for any account sorted chronologically. Which database optimization strategy should a solutions architect recommend to resolve the throttling issue while meeting the performance requirements?

  1. A
    Deploy an Amazon DynamoDB Accelerator (DAX) cluster to cache the transactions, and configure the application to write all transactions through the DAX endpoint.
  2. B
    Create a Global Secondary Index (GSI) with a partition key of `TransactionTimestamp` and a sort key of `AccountID`, and configure the application to write transactions directly to the GSI.
  3. Implement write sharding by appending a random integer suffix from 00 to 99 to the `AccountID` during writes, and query all sharded partitions in parallel using the application layer to merge the results.Answer
  4. D
    Convert the table to a global table and replicate it across multiple AWS regions, using latency-based routing to distribute the write operations across the regional endpoints.

Answer

Implement write sharding by appending a random integer suffix to the partition key, and query the sharded partitions in parallel to merge the results.
The correct strategy is to distribute the write load across multiple physical partitions using write sharding. DynamoDB limits any single partition key to a maximum of 1,0001,000 write capacity units (WCUs) per second. When a few accounts generate massive transaction volumes, their writes are throttled despite the table having on-demand capacity enabled. By appending a random integer suffix (such as 00 to 99) to the `AccountID`, the write operations for a single account are spread across 1010 physical partitions, elevating the limit to 10,00010,000 WCUs. The application can query all 1010 sharded partitions in parallel and merge the sorted streams, fulfilling the chronological query requirements with sub-second response times.

Step-by-Step Solution

1
Diagnose the partition bottleneck.
Identify that a single DynamoDB partition has a hard limit of 1,0001,000 write capacity units (WCUs) per second, which cannot be bypassed by table-level on-demand scaling if traffic is concentrated on a single key.
Understanding the physical constraints of DynamoDB partitions is necessary to address localized throttling.
2
Evaluate DynamoDB Accelerator (DAX) behavior for write operations.
Confirm that DAX is a write-through cache, meaning writes are committed to the base table synchronously and still count against the 1,0001,000 WCU partition limit.
Rule out caching as a write-throughput scaling solution.
3
Evaluate Global Secondary Index (GSI) capabilities.
Confirm that DynamoDB does not support direct writes to GSIs and that partitioning by a monotonically increasing timestamp creates a severe hot partition.
Rule out secondary index writes and verify database access patterns.
4
Evaluate Global Tables capabilities.
Determine that cross-region replication replicates writes asynchronously but does not increase the physical write limit of a single partition key inside any region.
Rule out regional replication as a mechanism for scaling single-key writes.
5
Design and verify a write sharding strategy.
By appending a random suffix (00 to 99), writes for a single account are distributed across up to 1010 partitions, increasing the single-account write limit to 10,00010,000 WCUs. Querying these partitions in parallel allows the application to merge results chronologically.
Select the correct pattern that distributes write load while preserving query capability.

Key Concept

Mitigating hot partition keys in DynamoDB using write sharding to scale beyond the single-partition write limit.
Rate this question

Topics

High-Performing Database Solutions

More questions from this topic