Idempotency tokens in DynamoDB - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Why use idempotency tokens in DynamoDB operations?

Imagine you send a request to add an item to a DynamoDB table, but the network is slow and you are unsure if the request succeeded. What is the main reason to use an idempotency token in this case?

A To encrypt the data before storing it in the table

B To ensure the request is processed only once even if sent multiple times

C To speed up the query response time

D To automatically delete duplicate items from the table

💡 Hint

Think about what happens if you send the same request twice by mistake.

Idempotency tokens help DynamoDB recognize repeated requests and avoid processing the same operation multiple times, preventing duplicate data.

❓ query_result

intermediate

What is the output of this DynamoDB PutItem with idempotency token?

Given a DynamoDB table with a primary key 'OrderId', you run this PutItem request twice with the same idempotency token. What will be the result?

DynamoDB

PutItem({
  TableName: 'Orders',
  Item: { OrderId: '123', Status: 'Pending' },
  ClientRequestToken: 'token-abc-123'
})

A The item is inserted once; the second request returns success without inserting again

B The item is inserted twice, creating duplicate entries

C The second request causes a ConditionalCheckFailedException

D Both requests fail with a ValidationException

💡 Hint

Think about how DynamoDB treats repeated requests with the same token.

DynamoDB uses the idempotency token to detect repeated requests and returns success without duplicating the item.

📝 Syntax

advanced

Which option correctly includes an idempotency token in a DynamoDB TransactWriteItems request?

Choose the correct syntax to add an idempotency token to a TransactWriteItems request in DynamoDB.

DynamoDB

TransactWriteItems({
  TransactItems: [
    { Put: { TableName: 'Orders', Item: { OrderId: '001', Status: 'New' } } }
  ],
  /* Where to add idempotency token? */
})

A Add ClientRequestToken inside the Item attribute

B Add ClientRequestToken inside each Put item object

C Add ClientRequestToken as a header in the HTTP request only

D Add ClientRequestToken: 'token-xyz-789' as a top-level parameter in TransactWriteItems

💡 Hint

Idempotency tokens apply to the whole transaction, not individual items.

The ClientRequestToken is a top-level parameter in TransactWriteItems to ensure the entire transaction is idempotent.

❓ optimization

advanced

How does using idempotency tokens optimize DynamoDB write operations?

Which of the following best explains how idempotency tokens optimize write operations in DynamoDB?

A They cache write results to speed up future reads

B They compress data before writing to reduce storage size

C They prevent duplicate writes by recognizing repeated requests, saving processing time and storage

D They automatically retry failed writes without user intervention

💡 Hint

Think about how avoiding duplicates helps system efficiency.

Idempotency tokens help DynamoDB avoid processing the same write multiple times, reducing unnecessary work and storage.

🔧 Debug

expert

What error occurs if you reuse an idempotency token with different request parameters?

You send a PutItem request with an idempotency token 'token-123' and item {OrderId: '1', Status: 'Pending'}. Later, you send another PutItem with the same token but item {OrderId: '1', Status: 'Shipped'}. What error will DynamoDB return?

A IdempotentParameterMismatchException

B ConditionalCheckFailedException

C ProvisionedThroughputExceededException

D ResourceNotFoundException

💡 Hint

Think about what happens if the same token is used with different data.

DynamoDB throws IdempotentParameterMismatchException when the same idempotency token is reused with different request parameters.

Practice

1. What is the main purpose of using idempotency tokens in DynamoDB operations?

easy

A. To encrypt data stored in the database

B. To prevent duplicate writes when the same request is retried

C. To speed up query performance by caching results

D. To automatically backup data at regular intervals

Solution

1. Step 1: Understand idempotency token role

   Idempotency tokens are unique values sent with requests to ensure the same operation is not applied multiple times.

2. Step 2: Identify the main benefit in DynamoDB

   This prevents duplicate writes if a request is retried due to network issues or timeouts.

3. Final Answer:

   To prevent duplicate writes when the same request is retried -> Option B

4. Quick Check:

   Idempotency tokens prevent duplicates = C [OK]

Hint: Idempotency tokens stop repeated writes on retries [OK]

Common Mistakes:

• Confusing idempotency tokens with encryption keys
• Thinking they improve query speed
• Assuming they trigger backups automatically

2. Which of the following is the correct way to include an idempotency token in a DynamoDB PutItem request using AWS SDK?

easy

A. "IdempotencyToken": "unique-token-value" inside the item attributes

B. Adding IdempotencyToken as a reserved keyword in the table schema

C. Setting IdempotencyToken as a parameter outside the item attributes

D. Using a conditional expression with attribute_not_exists(IdempotencyToken)

Solution

1. Step 1: Understand how idempotency tokens work in DynamoDB

   They are used with conditional expressions to ensure the item is only created if the token does not exist.

2. Step 2: Identify correct syntax for conditional check

   The expression attribute_not_exists(IdempotencyToken) prevents overwriting if the token is already present.

3. Final Answer:

   Using a conditional expression with attribute_not_exists(IdempotencyToken) -> Option D

4. Quick Check:

   Conditional check with attribute_not_exists = B [OK]

Hint: Use conditional expression attribute_not_exists for idempotency [OK]

Common Mistakes:

• Placing token inside item without condition causes duplicates
• Trying to set token outside request parameters incorrectly
• Assuming token is a reserved schema keyword

3. Given the following DynamoDB PutItem request with idempotency token condition:

{
  "TableName": "Orders",
  "Item": {"OrderId": {"S": "123"}, "IdempotencyToken": {"S": "abc-123"}},
  "ConditionExpression": "attribute_not_exists(IdempotencyToken)"
}

What happens if this request is sent twice with the same token?

medium

A. The first request succeeds; the second fails with a conditional check error

B. Both requests succeed and create duplicate items

C. Both requests fail due to token conflict

D. The second request overwrites the first item silently

Solution

1. Step 1: Analyze the condition expression effect

   The condition attribute_not_exists(IdempotencyToken) allows the write only if the token is not present.

2. Step 2: Predict behavior on repeated requests with same token

   The first request writes the item and token. The second request fails because the token now exists, triggering a conditional check failure.

3. Final Answer:

   The first request succeeds; the second fails with a conditional check error -> Option A

4. Quick Check:

   First write OK, second fails condition = D [OK]

Hint: Same token blocks second write with condition failure [OK]

Common Mistakes:

• Assuming both writes succeed causing duplicates
• Thinking second write silently overwrites
• Believing both writes fail

4. You wrote this DynamoDB PutItem request with idempotency token:

{
  "TableName": "Payments",
  "Item": {"PaymentId": {"S": "p001"}, "IdempotencyToken": {"S": "token-xyz"}},
  "ConditionExpression": "attribute_not_exists(IdempotencyToken)"
}

But you get a ConditionalCheckFailedException on the first request. What is the likely cause?

medium

A. An item with the same IdempotencyToken already exists in the table

B. The IdempotencyToken attribute is missing from the item

C. The table does not have a primary key defined

D. The ConditionExpression syntax is invalid

Solution

1. Step 1: Understand the meaning of ConditionalCheckFailedException

   This error means the condition attribute_not_exists(IdempotencyToken) was false, so the token attribute already exists.

2. Step 2: Identify why the first request fails

   If the token already exists in an item, the condition prevents overwriting, causing the failure.

3. Final Answer:

   An item with the same IdempotencyToken already exists in the table -> Option A

4. Quick Check:

   Token exists causes condition failure = A [OK]

Hint: Condition fails if token already exists in table [OK]

Common Mistakes:

• Assuming missing token causes this error
• Thinking primary key absence triggers this error
• Believing condition syntax is wrong

5. You want to design a DynamoDB table to support idempotent order creation using tokens. Which approach best ensures no duplicate orders are created when clients retry requests?

hard

A. Use a composite primary key with OrderId and IdempotencyToken and allow overwrites

B. Use OrderId as the primary key and store IdempotencyToken as a unique attribute with a conditional write checking attribute_not_exists(IdempotencyToken)

C. Use IdempotencyToken as the primary key and reject writes if the token exists

D. Do not store tokens; rely on client-side checks to avoid duplicates

Solution

1. Step 1: Consider uniqueness enforcement for idempotency

   Using IdempotencyToken as the primary key ensures each token is unique and prevents duplicates at the database level.

2. Step 2: Evaluate other options

   Use OrderId as the primary key and store IdempotencyToken as a unique attribute with a conditional write checking attribute_not_exists(IdempotencyToken) risks duplicates if tokens are not primary keys. Use a composite primary key with OrderId and IdempotencyToken and allow overwrites allows overwrites, breaking idempotency. Do not store tokens; rely on client-side checks to avoid duplicates relies on unreliable client checks.

3. Final Answer:

   Use IdempotencyToken as the primary key and reject writes if the token exists -> Option C

4. Quick Check:

   Primary key on token ensures uniqueness = A [OK]

Hint: Make token primary key to enforce uniqueness [OK]

Common Mistakes:

• Storing token as non-key attribute without condition
• Allowing overwrites with composite keys
• Relying only on client-side checks