Troubleshooting and Optimization

271 questions

All types271 Multiple choice138 Multiple select133

A smart home telemetry application stores real-time ambient device statuses in an Amazon DynamoDB table. Users retrieve the status of specific devices through a mobile app dashboard, which performs frequent key-value read requests by device ID. During peak usage hours, users experience high read latency, and the dashboard receives ProvisionedThroughputExceededException errors. CloudWatch metrics indicate that the table's total read capacity is not exceeded, but a small subset of highly active device IDs is causing hot partitions. The developer wants to deploy Amazon DynamoDB Accelerator (DAX) to resolve the latency and throttling issues. Which two actions must the developer take to achieve this objective?

Select all that apply

Deploy a DAX cluster and replace the standard DynamoDB client with the DAX client SDK in the application code.

Configure the read requests from the mobile application to use eventually consistent reads.

Modify the application code to perform Scan operations instead of GetItem operations to populate the cache.

Increase the provisioned Read Capacity Units (RCUs) on the DynamoDB table to absorb the spikes in read traffic.

Initialize the DAX client in the application code by hardcoding the AWS IAM access keys and secret keys.

Show answer & explanation

Answer: Deploy a DAX cluster and replace the standard DynamoDB client with the DAX client SDK in the application code.; Configure the read requests from the mobile application to use eventually consistent reads.

Answer

To resolve the throttling and latency issues using DAX, the developer must deploy the DAX cluster, use the DAX client SDK to point the application to the cache, and ensure read requests use eventually consistent reads so they can be cached.

To leverage DAX for sub-millisecond read latency and prevent hot partition throttling, the application must use the DAX client SDK to route reads through the cache. Additionally, the read operations must be configured as eventually consistent, because DAX does not cache strongly consistent reads in its Item Cache.

Step-by-Step Solution

Replace the standard DynamoDB client SDK with the DAX client SDK.

The application routes its API calls to the DAX cluster instead of directly to DynamoDB.

DAX requires a specialized client SDK that is API-compatible with DynamoDB to intercept and cache the requests.

Configure read requests to use eventually consistent reads.

DAX intercepts the GetItem and Query calls and saves the result in the Item Cache.

Strongly consistent reads bypass the DAX cache and hit the database directly, which would not resolve the hot partition throttling.

Key Concept

Integrating DAX requires utilizing the DAX client SDK and configuring reads to be eventually consistent to leverage the DAX Item Cache.

Question 262Question →

A software company operates a multi-tenant SaaS application that stores client organization profiles in an Amazon DynamoDB table. To minimize read latency for authorization checks, the developer deployed an Amazon DynamoDB Accelerator (DAX) cluster. However, an administrative microservice updates these organization profiles by writing directly to the DynamoDB table. Consequently, users report that profile updates take up to five minutes to reflect in the main application. Which of the following developer actions will resolve this cache staleness issue most efficiently?

Configure the administrative microservice to perform write operations through the DAX cluster client rather than directly to the DynamoDB table.

Modify the main application to perform a full Scan operation on the DAX cluster every five minutes to refresh the cache for all client organization profiles.

Increase the provisioned read capacity units (RCUs) and write capacity units (WCUs) of the underlying DynamoDB table to handle the direct updates without partition throttling.

Configure the Lambda functions in the main application to initialize a new DAX client connection on every request rather than reusing the client across execution contexts.

Show answer & explanation

Answer: Configure the administrative microservice to perform write operations through the DAX cluster client rather than directly to the DynamoDB table.

Answer

Configure the administrative microservice to perform write operations through the DAX cluster client rather than directly to the DynamoDB table.

Directing writes through the DAX cluster client ensures that DAX performs a write-through operation. This updates the DAX cache (item cache) synchronously while writing to the DynamoDB table, so subsequent reads immediately see the updated configuration.

Step-by-Step Solution

Analyze the cache staleness behavior.

Identified that writes bypassing the DAX cluster do not invalidate or update the item cache in DAX, leading to stale reads until the Time to Live (TTL) expires.

Understanding how DAX maintains cache consistency is necessary to troubleshoot staleness issues.

Determine the write pattern needed for DAX.

DAX is designed as a write-through cache. Directing write operations through the DAX client updates both the cache and the underlying DynamoDB table.

Using a write-through pattern ensures the cache remains consistent with the database immediately after writes.

Key Concept

DAX Cache Consistency and Write-Through Strategy

Question 263Question →

An IoT telemetry collection service named FleetVibe writes real-time status updates from delivery trucks to an Amazon DynamoDB table. The table is configured with provisioned write capacity and uses the FleetDivision attribute (e.g., 'US-East', 'EU-West') as the partition key. During peak hours, the application experiences write throttling and throws ProvisionedThroughputExceededException errors, even though the total consumed write capacity is well below the table's provisioned limit. Application logs reveal that the client application immediately fails and drops data upon receiving the throttling errors. Which TWO actions should the developer take to resolve the write throttling and prevent data loss? (Select TWO.)

Select all that apply

Update the application schema to append a random numerical suffix to the FleetDivision partition key before writing, and adjust the read logic to query across the suffixes.

Configure the AWS SDK client in the application to use exponential backoff with jitter for automatic retries when throttling errors occur.

Increase the overall provisioned Write Capacity Units (WCUs) of the table to scale up the throughput limits.

Place an Amazon SQS queue in front of the table and set the SQS message visibility timeout to a low value like 2 seconds to force rapid retries.

Modify the client application to retrieve records using a sequential Scan operation with a FilterExpression on FleetDivision to bypass partition limits.

Show answer & explanation

Answer: Update the application schema to append a random numerical suffix to the FleetDivision partition key before writing, and adjust the read logic to query across the suffixes.; Configure the AWS SDK client in the application to use exponential backoff with jitter for automatic retries when throttling errors occur.

Answer

The correct solutions are to append a random numerical suffix to the partition key to distribute write traffic, and to configure the AWS SDK client to use exponential backoff with jitter to handle retries.

The correct actions are to append a random numerical suffix (sharding) to the FleetDivision partition key and to configure the AWS SDK client to use exponential backoff with jitter. Appending a random suffix distributes write requests across multiple physical partitions, which mitigates hot partition issues caused by low-entropy keys. Updating the SDK client to use exponential backoff and jitter ensures that the application handles transient throttling errors gracefully by retrying them over increasing, randomized intervals, preventing immediate failures and data loss.

Step-by-Step Solution

Identify the cause of throttling by comparing consumed throughput with provisioned throughput.

Throttling is localized to specific partition keys (hot partition issue) because overall consumed capacity is below the table limit.

Before applying fixes, the developer must determine if the bottleneck is a hot key design rather than overall table limit exhaustion.

Redesign the partition key schema to introduce entropy.

The application appends a random suffix to the FleetDivision partition key, distributing the write workload across multiple physical partitions.

Distributing the writes prevents any single partition from exceeding the 1,000 WCUs per second hard limit.

Enable robust retry logic in the AWS SDK client configuration.

The application retries transient failures using exponential backoff and jitter, preventing immediate client-side data loss.

Transient throttling can still occur during spikes; exponential backoff avoids overwhelming the database while ensuring all writes eventually succeed.

Key Concept

Resolving DynamoDB throttling issues requires distributing the workload evenly using partition key sharding (random suffixes) and handling client-side retries with exponential backoff and jitter.

Question 264Question →

A sports media website uses Amazon DynamoDB to store and retrieve live match statistics. During high-profile matches, a sudden surge in read requests for a small set of popular matches results in DynamoDB throttling and increased latency. A developer decides to implement an Amazon DynamoDB Accelerator (DAX) cluster to optimize read performance. Which of the following developer actions are required to successfully cache these read operations and resolve the bottleneck? (Select two.)

Select all that apply

Configure the application to use the DAX SDK client to route API calls to the DAX cluster endpoint.

Ensure the application performs eventually consistent reads rather than strongly consistent reads for cached items.

Configure DynamoDB auto-scaling to dynamically increase the provisioned Read Capacity Units (RCUs) of the table during peak hours.

Refactor the read logic to perform a Scan operation with a filter expression instead of a Query to retrieve match statistics.

Implement AWS Systems Manager Parameter Store to manage and automatically rotate the IAM credentials used by the DAX cluster nodes.

Show answer & explanation

Answer: Configure the application to use the DAX SDK client to route API calls to the DAX cluster endpoint.; Ensure the application performs eventually consistent reads rather than strongly consistent reads for cached items.

Answer

Configure the application to use the DAX SDK client to route API calls to the DAX cluster endpoint, and ensure the application performs eventually consistent reads rather than strongly consistent reads for cached items.

To cache DynamoDB read requests using DAX, the application must interact with the cluster via the DAX client SDK. Additionally, DAX is designed to cache eventually consistent read operations in its item cache, whereas strongly consistent reads are forwarded directly to DynamoDB, bypassing the cache.

Step-by-Step Solution

Select the correct SDK client for caching operations.

The application code is updated to instantiate the DAX client SDK rather than the default DynamoDB client SDK, directing requests to the DAX cluster.

The standard SDK will bypass DAX entirely and communicate directly with DynamoDB, preventing caching from occurring.

Adjust the consistency model of read requests.

Ensure all read requests targeting cached items are set to eventually consistent (which is the default).

Strongly consistent reads are passed directly to the DynamoDB database by DAX and do not populate or read from the DAX item cache.

Key Concept

DynamoDB Accelerator (DAX) client configuration and read consistency caching rules

Question 265Question →

A fitness tracking application named FitPulse records real-time workout metrics from users' smartwatches into an Amazon DynamoDB table. The table is configured with provisioned read and write capacity. The partition key is `WorkoutDate` (formatted as YYYY-MM-DD), and the sort key is `UserId`. During peak hours (e.g., weekday evenings), the application experiences a high volume of write failures, and the backend logs display `ProvisionedThroughputExceededException` errors, even though the total consumed write capacity is well below the table's provisioned limit. Which combination of actions will resolve this issue? (Select TWO options.)

Select all that apply

Redesign the partition key schema by appending a random suffix to the WorkoutDate to distribute writes across multiple partitions.

Configure the AWS SDK client in the application to use exponential backoff and jitter for write retries.

Increase the provisioned write capacity units (WCUs) of the DynamoDB table to accommodate the total aggregate throughput.

Modify the application to use a Scan operation instead of a Query operation to retrieve existing records before performing the write.

Increase the SQS queue's visibility timeout to give write consumers more time to retry throttling errors before message visibility expires.

Show answer & explanation

Answer: Redesign the partition key schema by appending a random suffix to the WorkoutDate to distribute writes across multiple partitions.; Configure the AWS SDK client in the application to use exponential backoff and jitter for write retries.

Answer

Redesign the partition key schema by appending a random suffix to the WorkoutDate to distribute writes across multiple partitions, and configure the AWS SDK client in the application to use exponential backoff and jitter for write retries.

The application is encountering partition throttling because using a low-cardinality value like WorkoutDate as the partition key concentrates all writes on the same day to a single physical partition (a hot key issue). Appending a random suffix to the WorkoutDate distributes writes across multiple partitions. Additionally, configuring the AWS SDK with exponential backoff and jitter helps the application gracefully handle transient throttling errors and retry requests.

Step-by-Step Solution

Analyze the error and metrics.

The ProvisionedThroughputExceededException occurs despite total consumed capacity being below provisioned limits, indicating a hot partition key issue where writes are concentrated on a single partition key (WorkoutDate).

Identifying the root cause is necessary before applying the correct optimization strategy.

Select a partition key distribution strategy.

By appending a random suffix to WorkoutDate, the data is distributed across multiple partitions, resolving the hot partition issue.

DynamoDB partitions are based on the partition key hash value; higher entropy prevents hot spots.

Configure application retry mechanisms.

Implementing exponential backoff and jitter in the SDK configuration allows the application to retry failed requests efficiently without overwhelming the database.

Transient network spikes or minor partition adjustments can still cause momentary throttling, which retries can mitigate.

Key Concept

Partition key sharding and SDK retry strategies are used to resolve DynamoDB partition-level throttling issues caused by hot keys.

Question 266Question →

An agricultural IoT application named 'CropSense' collects hourly soil moisture data from thousands of sensors in a region. The sensor data is written to an Amazon DynamoDB table. The table is configured with a partition key of `SensorType` (which has only three distinct values: 'Moisture', 'Temperature', and 'Acidity') and a sort key of `Timestamp`. During peak reporting windows, the application experiences a high volume of `ProvisionedThroughputExceededException` errors, even though the total read/write capacity units consumed are well below the table's allocated capacity. Which of the following actions is the most appropriate way to resolve this throttling issue?

Increase the table's provisioned write capacity units (WCUs) to scale up the overall write throughput limit of the table.

Increase the visibility timeout of the upstream Amazon SQS queue to allow more time for the application to process each write request.

Redesign the partition key schema by appending a random or calculated numeric suffix to the partition key (e.g., Moisture_N, where

N

is a random integer between

1

and

10

) to distribute write operations across multiple partition keys.

Hardcode the AWS access keys directly within the SDK client initialization configuration to eliminate credential provider chain lookup latency.

Show answer & explanation

Answer: Redesign the partition key schema by appending a random or calculated numeric suffix to the partition key (e.g., Moisture_N, where $N$ is a random integer between $1$ and $10$ ) to distribute write operations across multiple partition keys.

Answer

Redesign the partition key schema by appending a random or calculated numeric suffix to the partition key (e.g., Moisture_N, where

N

is a random integer between

1

and

10

) to distribute write operations across multiple partition keys.

The throttling is caused by a hot partition key because the partition key (SensorType) has low cardinality (only three values). This concentrates writes on a small number of physical partitions, exceeding the partition-level throughput limits. Appending a random or calculated numeric suffix to the partition key distributes the write operations across a larger number of logical keys, solving the partition-level bottleneck.

Step-by-Step Solution

Analyze the DynamoDB table design and identify the partition key cardinality.

The partition key has only three distinct values: 'Moisture', 'Temperature', and 'Acidity'.

This low cardinality causes all writes to be directed to only three logical partitions, creating a hot partition issue.

Differentiate between table-level capacity limits and partition-level throughput limits.

Throttling occurs because the write volume to one of the three partitions exceeds the partition limit (e.g.,

1000

WCUs per second), even if the overall table capacity is not exceeded.

Scaling up total capacity (WCUs) will not help if individual partition limits are exceeded.

Implement write sharding by adding a suffix to the partition key.

Using a schema like `SensorType_N` distributes the data across multiple partitions.

This evenly distributes the write throughput workload, resolving the ProvisionedThroughputExceededException errors.

Key Concept

Write sharding (appending a suffix to partition keys) to distribute highly skewed workloads in Amazon DynamoDB.

Question 267Question →

A news publishing platform named 'PressPulse' records real-time article view events in an Amazon DynamoDB table. The table is configured with provisioned write capacity and uses ArticleCategory as the partition key. During breaking news events, views for a single category spike dramatically, resulting in ProvisionedThroughputExceededException errors, even though the total consumed capacity is well below the table's total provisioned threshold. Additionally, the application's SDK client fails immediately without retrying when a write request is throttled. Which TWO actions should the developer take to resolve the throttling and improve application resilience? (Select TWO.)

Select all that apply

Append a random integer suffix to the partition key value before writing to distribute the write load across multiple partition keys.

Configure the AWS SDK client to use exponential backoff and jitter for retrying throttled write requests.

Increase the visibility timeout of the Amazon SQS queue that buffers incoming page view events.

Execute a Scan operation with a filter expression on the backend to distribute read and write capacity usage.

Hardcode credentials for a secondary IAM user with full DynamoDB permissions in the SDK client configuration to bypass limits.

Show answer & explanation

Answer: Append a random integer suffix to the partition key value before writing to distribute the write load across multiple partition keys.; Configure the AWS SDK client to use exponential backoff and jitter for retrying throttled write requests.

Answer

To resolve the throttling and improve resilience, append a random integer suffix to the partition key value (write sharding) and configure the AWS SDK client to use exponential backoff and jitter for retries.

Appending a random integer suffix to the partition key (such as ArticleCategory) distributes the write load across multiple partition keys and physical partitions, alleviating the hot partition throttling issue. Configuring the AWS SDK client with exponential backoff and jitter allows the application to handle transient throttling errors gracefully by spreading out retry attempts.

Step-by-Step Solution

Analyze the cause of the ProvisionedThroughputExceededException.

Identify that a single ArticleCategory (the partition key) is receiving disproportionate traffic, creating a hot partition key.

Throttling occurs at the partition level when a single partition key's throughput limit is exceeded, even if the overall table capacity is not.

Implement write sharding by modifying the partition key schema.

Append a random integer suffix (e.g., ArticleCategory_1, ArticleCategory_2) to distribute writes across multiple partition keys.

This spreads the traffic across multiple physical partitions, resolving the hot partition issue.

Configure client-side error handling.

Modify the AWS SDK client settings to enable exponential backoff and jitter for failed requests.

This allows the client to retry throttled requests gracefully rather than failing immediately, smoothing out traffic spikes.

Key Concept

Resolving DynamoDB throttling issues caused by hot partition keys using write sharding and configuring client-side SDK retry logic with backoff and jitter.

Question 268Question →

A ticketing application named 'PassGate' registers entry scans for high-attendance live events in a DynamoDB table. The table is configured with provisioned write capacity units (WCUs). During the check-in period for a major music concert, the application frequently encounters ProvisionedThroughputExceededException errors. CloudWatch metrics indicate that the table's overall consumed WCUs are well below the provisioned threshold, but a single partition key matching the popular EventID is receiving almost all the write traffic. Which action should the developer take to resolve this throttling issue?

Increase the visibility timeout of the SQS queue that feeds ticket scans to the application, allowing more time for message processing.

Modify the table schema to append a random or calculated suffix to the EventID partition key, distributing the write load across multiple partitions.

Transition the application's read operations to perform a full Scan with filter expressions instead of using Query operations.

Embed static access keys in the application's SDK client configuration to ensure client credentials do not expire during peak throughput.

Show answer & explanation

Answer: Modify the table schema to append a random or calculated suffix to the EventID partition key, distributing the write load across multiple partitions.

Answer

Modify the table schema to append a random or calculated suffix to the EventID partition key, distributing the write load across multiple partitions.

The correct answer is correct because salting the partition key (appending a random or calculated suffix) distributes the writes across multiple logical partitions, preventing a hot key issue on a single partition.

Step-by-Step Solution

Identify the root cause of the DynamoDB throttling.

CloudWatch metrics show a disproportionate amount of write traffic targeting a single partition key value (the EventID).

A single hot partition key limits throughput to the maximum capacity of a single partition, regardless of the overall table provisioning.

Evaluate partition key design options to distribute write load.

Adding a random or calculated suffix (salting) to the partition key distributes the write load across multiple partitions.

This prevents write traffic from bottlenecking on a single physical partition by spreading it across multiple sub-partitions.

Key Concept

DynamoDB Partition Key Salting and Hot Partitions

Estimated Time:1m 30s

Question 269Question →

A logistics delivery application named 'RouteSpeed' updates the status of packages in an Amazon DynamoDB table. The partition key is `delivery_date` and the sort key is `package_id`. During peak delivery hours on a major shopping holiday, the application encounters a high rate of `ProvisionedThroughputExceededException` errors. CloudWatch metrics indicate that the table's total consumed write capacity is well below the provisioned write capacity.

Which TWO actions should the developer take to resolve these throttling issues? (Select TWO.)

Select all that apply

Redesign the partition key schema by appending a randomized or calculated suffix to the partition key value to distribute write requests across multiple physical partitions.

Configure the AWS SDK client in the application to use exponential backoff and jitter for retrying throttled write requests.

Increase the visibility timeout of the Amazon SQS queue that feeds the status updates to the application to prevent messages from returning to the queue.

Modify the application to perform a Scan operation instead of a Query operation to verify if a package partition has available capacity before writing.

Hardcode static AWS credentials in the application's SDK client configuration to bypass the default credential provider chain and reduce connection establishment latency.

Show answer & explanation

Answer: Redesign the partition key schema by appending a randomized or calculated suffix to the partition key value to distribute write requests across multiple physical partitions.; Configure the AWS SDK client in the application to use exponential backoff and jitter for retrying throttled write requests.

Answer

To resolve the throttling issues, the developer must redesign the partition key schema by appending a suffix to distribute writes and configure the AWS SDK client to use exponential backoff and jitter for retrying failed requests.

Redesigning the partition key by appending a randomized or calculated suffix distributes the write load across multiple physical partitions, preventing a single partition from becoming hot. Additionally, configuring the SDK client with exponential backoff and jitter ensures that the application handles temporary write spikes gracefully by retrying requests after increasing delays.

Step-by-Step Solution

Analyze the table configuration and error patterns to identify if writes are unevenly distributed.

Discovered that the partition key is a date string with low entropy, causing all writes on a given day to target a single physical partition.

Uneven distribution causes single partition limits to be reached even when the overall table capacity is sufficient.

Introduce a calculated suffix (e.g.,

1

N

) to the partition key value during write operations.

Writes are evenly distributed across multiple physical partitions.

Increasing the entropy of the partition key balances the write load.

Configure the AWS SDK client to implement exponential backoff with randomized delay (jitter).

Transient throttling errors are automatically retried with spacing to prevent request collisions.

Ensures the application handles transient load spikes without failing operations.

Key Concept

Mitigating DynamoDB hot partitions and using SDK retry strategies

Question 270Question →

A corporate employee portal retrieves employee profile metadata and contact information from an Amazon DynamoDB table. During morning log-in hours, the portal experiences high read latency and ProvisionedThroughputExceededException errors when fetching the profiles of executive leadership, which are queried by many employees. The developer wants to reduce read latency to sub-millisecond levels for these read-heavy requests without modifying the existing query API calls. Which of the following actions should the developer take? (Select two.)

Select all that apply

Deploy an Amazon DynamoDB Accelerator (DAX) cluster to cache the read requests.

Configure the application to use the DAX client SDK to direct read requests to the DAX cluster.

Increase the provisioned Read Capacity Units (RCUs) on the DynamoDB table to absorb the peak traffic.

Modify the application to perform Scan operations with Parallel Scan enabled to retrieve employee profiles.

Configure the DAX client by hardcoding the developer's AWS Access Key ID and Secret Access Key directly in the application code.

Show answer & explanation

Answer: Deploy an Amazon DynamoDB Accelerator (DAX) cluster to cache the read requests.; Configure the application to use the DAX client SDK to direct read requests to the DAX cluster.

Answer

To optimize read performance and achieve sub-millisecond latency for the hot partition requests without changing query logic, the developer should deploy an Amazon DynamoDB Accelerator (DAX) cluster and update the application to use the DAX client SDK.

The correct options recommend deploying a DynamoDB Accelerator (DAX) cluster and using the DAX client SDK. DAX acts as a managed write-through cache that provides sub-millisecond response times for read-intensive workloads. Because the DAX SDK is API-compatible with DynamoDB, it serves as a drop-in replacement that requires no changes to the existing query API calls.

Step-by-Step Solution

Identify the performance requirement and constraint.

The application requires sub-millisecond latency for frequently accessed items (hot partitions) without changing the query API calls.

This points to a caching layer that is compatible with the DynamoDB API.

Select the appropriate caching solution.

Amazon DynamoDB Accelerator (DAX) is selected as it is a fully managed, highly available, in-memory cache specifically designed for DynamoDB that delivers sub-millisecond latency.

DAX API is compatible with DynamoDB, meaning the application query logic does not need to change.

Configure the application to communicate with the cache.

The application code is updated to use the DAX client SDK instead of the standard AWS SDK for DynamoDB.

The DAX SDK acts as a drop-in replacement, directing requests to the DAX cluster endpoint and falling back to DynamoDB if necessary.

Key Concept

Amazon DynamoDB Accelerator (DAX) is an in-memory write-through cache designed to reduce read response times to sub-milliseconds for DynamoDB tables, requiring minimal application modifications via the DAX client SDK.

Question 271Question →

A customer loyalty rewards platform named "LoyaltyLink" processes member transactions and records reward point updates in an Amazon DynamoDB table. During a flash sale event, the application experiences a high volume of writes and starts throwing `ProvisionedThroughputExceededException` errors. The DynamoDB table partition key is `transaction_date` (formatted as YYYY-MM-DD), and the sort key is `member_id`. Although the total write throughput is well within the table's provisioned write capacity units (WCUs), the requests are heavily skewed towards the current date, causing throttling on a single partition. Which of the following approaches should a developer implement to resolve this throttling issue?

Redesign the partition key schema by appending a random suffix (such as a number from

1

N

) to the `transaction_date` partition key during writes, and update the application logic to query across all salted partitions.

Increase the provisioned Write Capacity Units (WCUs) of the DynamoDB table to

5000

to accommodate the temporary spike in write activity.

Integrate an Amazon SQS queue to buffer write requests and increase the SQS visibility timeout to

600

seconds to prevent message processing duplicates.

Reconfigure the application to perform parallel Scan operations across

10

segments to distribute the write workload evenly across the physical partitions.

Show answer & explanation

Answer: Redesign the partition key schema by appending a random suffix (such as a number from $1$ to $N$ ) to the `transaction_date` partition key during writes, and update the application logic to query across all salted partitions.

Answer

Redesign the partition key schema by appending a random suffix (such as a number from

1

N

) to the `transaction_date` partition key during writes, and update the application logic to query across all salted partitions.

The correct answer is to redesign the partition key schema by appending a random suffix to the `transaction_date` partition key during writes. Because DynamoDB partitions have a maximum write throughput limit of

1000

WCUs, using a partition key with low cardinality (such as a single date for all transactions on that day) causes all writes to target a single partition, resulting in throttling. Adding a random suffix (salting) distributes the items across multiple partitions, overcoming the single-partition write limit.

Step-by-Step Solution

Identify the cause of the ProvisionedThroughputExceededException when total consumed capacity is within limits.

The issue is a hot partition key caused by using a highly skewed value (`transaction_date`), which routes all writes for a single day to the same physical partition, hitting the single-partition limit of

1000

WCUs.

Understanding the physical limits of DynamoDB partitions is necessary to diagnose why scaling up overall capacity fails to resolve the issue.

Evaluate the correct design pattern for handling hot partition keys during writes.

Appending a random suffix (write sharding/salting) to the partition key distributes the write workload across multiple logical partitions.

Using a random suffix allows writes to be spread across multiple physical partitions, multiplying the maximum throughput for a single date.

Determine the changes required for read operations.

The application must be updated to query all potential salted partition keys (scatter-gather) to retrieve the full set of transactions for a given date.

Querying salted keys ensures that data can still be read reliably even though it is distributed across multiple partitions.

Key Concept

Handling DynamoDB hot partition keys using write sharding (salting) to distribute throughput across physical partitions.

PreviousPage 14 / 14

Troubleshooting and Optimization

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes