SAA-C03 Design High-Performing Architectures Practice Question

A new feature stores user events in DynamoDB. Each event must be fetched by user_id and sorted by event_time. The team expects many different users and wants to avoid a single hot partition. Which partition key design is best?

⚠ Common exam trap

A common mix-up: candidates choose a constant partition key (Option A) thinking it simplifies queries, but they overlook that DynamoDB's scalability depends on partition key cardinality, and a single partition key creates a bottleneck that defeats the purpose of a NoSQL database.

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 user_id as the partition key and event_time as the sort key.

Using `user_id` as the partition key ensures each user's events are stored in a separate partition, distributing the workload evenly and avoiding hot partitions. Adding `event_time` as the sort key allows DynamoDB to efficiently retrieve events for a given user in sorted order using a Query operation, which is both fast and cost-effective.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
Use a constant partition key value (for example, partition_key='events') and store user_id as an attribute.
Why it's wrong here
A constant partition key would concentrate all events into one partition, creating a hot partition risk. Queries by user_id would not be efficient without redesign and could exceed throughput limits. It defeats horizontal distribution.
✓
Use user_id as the partition key and event_time as the sort key.
Why this is correct
Using user_id as the partition key spreads data across many partitions based on user distribution. event_time as the sort key supports efficient range queries and retrieving events in time order per user. This design matches the stated access pattern and reduces hot partition likelihood.
✗
Use event_time as the partition key and user_id as an attribute to query later.
Why it's wrong here
Partitioning by event_time can still create hotspots if many events share the same time buckets. It also makes queries by user_id inefficient because user_id is not the partition key. The access pattern says user_id must drive retrieval.
✗
Use a randomly generated UUID as the partition key and query by user_id using a full table scan.
Why it's wrong here
A UUID partition key prevents efficient direct lookups by user_id and forces scans, which are slow and costly at scale. Full table scans do not meet typical performance needs. The design should align partition key with the query pattern.

Go deeper

SAA-C03 Design High-Performing Architectures Practice Question

Why each option matters

Option-by-option breakdown

Related to this question