Write sharding in DynamoDB - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

What is the main purpose of write sharding in DynamoDB?

Write sharding is used in DynamoDB to:

A Distribute write requests across multiple partitions to increase write throughput

B Encrypt data at rest for security

C Automatically backup data to S3

D Reduce read latency by caching data

💡 Hint

Think about how DynamoDB handles many writes at once.

Write sharding spreads write load across partitions to avoid throttling and improve performance.

❓ query_result

intermediate

What is the output count of items after applying write sharding with 3 shards?

Suppose you have a table with 9 items and you apply write sharding with 3 shards by adding a shard key with values 0, 1, or 2. How many total items will be in the table after sharding?

A 3

B 9

C 27

D 0

💡 Hint

Each original item is duplicated across shards with different shard keys.

Each of the 9 items is duplicated 3 times with different shard keys, so total items = 9 * 3 = 27.

📝 Syntax

advanced

Which DynamoDB update expression correctly increments a shard counter?

Given a DynamoDB item with attribute shardCount, which update expression correctly increments it by 1?

DynamoDB

UpdateExpression = ?

A SET shardCount = shardCount + :inc

B ADD shardCount :inc

C INCREMENT shardCount BY 1

D SET shardCount += 1

💡 Hint

DynamoDB uses ADD to increment numeric attributes.

The ADD keyword increments numeric attributes atomically. Other options are invalid syntax.

❓ optimization

advanced

How does write sharding improve DynamoDB write capacity usage?

Choose the best explanation for how write sharding optimizes write capacity in DynamoDB.

A It caches writes in memory before sending to DynamoDB

B It compresses data to reduce storage size

C It batches writes into a single request to reduce network calls

D It spreads writes across multiple partition keys to avoid hot partitions and throttling

💡 Hint

Think about how DynamoDB partitions data internally.

Write sharding distributes writes across different partition keys, preventing any single partition from becoming a bottleneck.

🔧 Debug

expert

Why does this write sharding implementation cause throttling errors?

You implemented write sharding by adding a random shard key from 0 to 4 to each item. However, you still get throttling errors on writes. What is the most likely cause?

Code snippet:

shard_key = random.randint(0, 4)
item['shard'] = shard_key
put_item(item)

A The shard key is not part of the partition key, so writes still go to the same partition

B Random shard keys cause duplicate items and data corruption

C The code does not batch writes, causing network overhead

D The shard key values are too small, causing uneven distribution

💡 Hint

Check how DynamoDB partitions data based on keys.

If the shard key is not included in the partition key, DynamoDB does not distribute writes across partitions, causing hot partitions and throttling.

Practice

1. What is the main purpose of write sharding in DynamoDB?

easy

A. To backup data automatically to S3

B. To spread write load across multiple partitions by adding shard IDs

C. To encrypt data at rest for security

D. To reduce read latency by caching data locally

Solution

1. Step 1: Understand write sharding concept

   Write sharding adds shard IDs to partition keys to distribute writes evenly.

2. Step 2: Identify the main goal

   This distribution avoids hot partitions and improves write performance.

3. Final Answer:

   To spread write load across multiple partitions by adding shard IDs -> Option B

4. Quick Check:

   Write sharding = spreading writes [OK]

Hint: Write sharding spreads writes by adding shard IDs [OK]

Common Mistakes:

• Confusing write sharding with read caching
• Thinking it encrypts data
• Assuming it handles backups

2. Which of the following is the correct way to implement write sharding in a DynamoDB partition key?

easy

A. Use a fixed partition key without any shard ID

B. Use the sort key as the shard ID

C. Append a random shard ID to the partition key before writing

D. Write all data to a single partition key

Solution

1. Step 1: Recall write sharding method

   Write sharding requires adding a shard ID to the partition key to distribute writes.

2. Step 2: Identify correct implementation

   Appending a random shard ID to the partition key spreads writes across partitions.

3. Final Answer:

   Append a random shard ID to the partition key before writing -> Option C

4. Quick Check:

   Shard ID + partition key = write sharding [OK]

Hint: Add random shard ID to partition key for sharding [OK]

Common Mistakes:

• Not adding shard ID at all
• Using sort key as shard ID incorrectly
• Writing all data to one partition

3. Given the following code snippet for write sharding, what is the expected effect?

shard_id = random.randint(0, 4)
partition_key = f"user#{user_id}#{shard_id}"
dynamodb_table.put_item(Item={"PK": partition_key, "Data": data})

medium

A. Writes are distributed across 5 partitions reducing hot spots

B. All writes go to the same partition causing throttling

C. Writes fail due to invalid partition key format

D. Data is only readable by shard_id 0

Solution

1. Step 1: Analyze shard ID usage

   The shard_id is a random number from 0 to 4, appended to the partition key.

2. Step 2: Understand partition key effect

   This creates 5 different partition keys for the same user, spreading writes across 5 partitions.

3. Final Answer:

   Writes are distributed across 5 partitions reducing hot spots -> Option A

4. Quick Check:

   Random shard ID 0-4 = 5 partitions [OK]

Hint: Random shard ID 0-4 means 5 partitions [OK]

Common Mistakes:

• Assuming all writes go to one partition
• Thinking partition key format is invalid
• Believing data is restricted by shard ID

4. You implemented write sharding by appending shard IDs to partition keys, but you notice some writes still cause throttling. What is the likely cause?

medium

A. Shard ID range is too small causing uneven distribution

B. You forgot to add shard ID to the sort key

C. You used a random shard ID but did not update the partition key

D. DynamoDB does not support write sharding

Solution

1. Step 1: Check shard ID range

   If the shard ID range is too small, writes cluster on few partitions causing throttling.

2. Step 2: Verify correct key usage

   Shard ID must be part of the partition key, not sort key, and must cover enough range.

3. Final Answer:

   Shard ID range is too small causing uneven distribution -> Option A

4. Quick Check:

   Small shard range = hot partitions [OK]

Hint: Use enough shard IDs to spread writes evenly [OK]

Common Mistakes:

• Adding shard ID to sort key instead of partition key
• Not updating partition key with shard ID
• Believing DynamoDB disallows sharding

5. You want to design a write sharding strategy for a DynamoDB table with very high write traffic on user data. Which approach best balances write load and allows efficient reads?

hard

A. Write all data to a single partition key and batch writes

B. Use user ID as partition key without sharding; rely on DynamoDB auto-scaling

C. Add shard ID to sort key and keep partition key as user ID

D. Add a random shard ID (0-9) to the partition key and store user data in each shard; aggregate reads by querying all shards

Solution

1. Step 1: Evaluate write sharding options

   Adding a random shard ID (0-9) to partition key spreads writes across 10 partitions.

2. Step 2: Consider read strategy

   Reads require querying all shards and aggregating results, which is manageable for balanced load.

3. Step 3: Compare other options

   Using no sharding risks throttling; shard ID in sort key does not distribute writes; single partition causes hot spots.

4. Final Answer:

   Add a random shard ID (0-9) to the partition key and store user data in each shard; aggregate reads by querying all shards -> Option D

5. Quick Check:

   Shard ID in partition key + aggregate reads = balanced writes [OK]

Hint: Shard in partition key, aggregate reads from all shards [OK]

Common Mistakes:

• Not sharding partition key causing hot partitions
• Adding shard ID to sort key only
• Ignoring read complexity after sharding