How to Fix DynamoDB Write Throttling Using a High-Cardinality Partition Key
A DynamoDB table for a travel booking site has a partition key based only on the current date. Write throttling occurs during business hours. What is the best design change? The design must avoid adding custom operational scripts.
Quick Answer
The answer is to use a higher-cardinality partition key that distributes writes across partitions. This is correct because a low-cardinality key like the current date funnels all writes into a single partition, causing DynamoDB write throttling when traffic spikes during business hours. By designing a high-cardinality partition key—such as combining the date with a random suffix or user ID—you ensure writes are spread evenly across partitions, fully utilizing provisioned write capacity without needing custom scripts. On the SAA-C03 exam, this scenario tests your understanding of partition design and hot partition mitigation, a common trap being to overcomplicate solutions with scripts or secondary indexes. The key insight is that DynamoDB’s throughput is per-partition, so a single hot partition throttles even if total capacity is unused. Memory tip: “Low cardinality, high throttling; high cardinality, smooth sailing.”
⚠ Common exam trap
It's easy for candidates to think adding a GSI (Option A) solves the issue, but GSIs inherit the same partition key design flaws and can also throttle independently.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Use a higher-cardinality partition key that distributes writes across partitions
Using a low-cardinality partition key like the current date causes all writes to land on a single partition, leading to throttling. By designing a higher-cardinality key (e.g., combining date with a random suffix or user ID), writes are distributed evenly across partitions, fully utilizing the provisioned write capacity without custom scripts.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Create a global secondary index with the same date key
Why it's wrong here
A GSI with the same hot key can suffer the same partition problem.
- ✗
Move the table to S3 Glacier Instant Retrieval
Why it's wrong here
S3 Glacier is object storage and not a DynamoDB write scaling solution.
- ✗
Reduce the table's write capacity
Why it's wrong here
Reducing capacity worsens throttling.
- ✓
Use a higher-cardinality partition key that distributes writes across partitions
Why this is correct
A low-cardinality hot partition causes throttling; a better key spreads writes more evenly.
Go deeper
Related to this question
About these practice questions
One of 302 original SAA-C03 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
Same concept, more angles
2 more ways this is tested on SAA-C03
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. A DynamoDB table for a travel booking site has a partition key based only on the current date. Write throttling occurs during business hours. What is the best design change? The architecture review board prefers a managed AWS-native control.
hard- A.Create a global secondary index with the same date key
- B.Move the table to S3 Glacier Instant Retrieval
- C.Reduce the table's write capacity
- ✓ D.Use a higher-cardinality partition key that distributes writes across partitions
Why D: Using a low-cardinality partition key like the current date causes all writes to land on a single partition, leading to throttling. By choosing a higher-cardinality partition key (e.g., combining date with a user ID or booking ID), writes are distributed evenly across multiple partitions, leveraging DynamoDB's internal partitioning to handle the throughput. This is a managed, AWS-native design change that resolves hot partition issues without additional services.
Variation 2. A DynamoDB table for a travel booking site has a partition key based only on the current date. Write throttling occurs during business hours. What is the best design change?
hard- A.Create a global secondary index with the same date key
- B.Move the table to S3 Glacier Instant Retrieval
- C.Reduce the table's write capacity
- ✓ D.Use a higher-cardinality partition key that distributes writes across partitions
Why D: Using a low-cardinality partition key like the current date concentrates all writes into a single partition, causing throttling when write demand exceeds that partition's 1,000 WCU limit. A higher-cardinality key (e.g., combining date with user ID or session ID) distributes writes evenly across multiple partitions, allowing the table to use its full provisioned write capacity without throttling.
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This SAA-C03 practice question is part of Courseiva's free Amazon Web Services certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the SAA-C03 exam.