Batch limits and retries in DynamoDB - Time & Space Complexity
When working with DynamoDB batch operations, it is important to understand how the time to complete requests changes as the number of items grows.
We want to know how batch limits and retries affect the total time taken.
Analyze the time complexity of the following code snippet.
// Batch write items with retry on unprocessed items
const batchWrite = async (items) => {
const BATCH_SIZE = 25;
let batches = [];
for (let i = 0; i < items.length; i += BATCH_SIZE) {
batches.push(items.slice(i, i + BATCH_SIZE).map(item => ({ PutRequest: { Item: item } })));
}
for (const batch of batches) {
let unprocessed = batch;
while (unprocessed.length > 0) {
const response = await dynamoDB.batchWrite({ RequestItems: { "MyTable": unprocessed } }).promise();
unprocessed = response.UnprocessedItems["MyTable"] || [];
}
}
};
This code splits items into batches of 25, sends each batch, and retries any unprocessed items until all are written.
Identify the loops, recursion, array traversals that repeat.
- Primary operation: Sending batch write requests to DynamoDB.
- How many times: Once per batch, plus additional retries for unprocessed items.
- The outer loop splits items into batches of 25, so it runs about n/25 times.
- The inner while loop retries unprocessed items until none remain, repeating as needed.
As the number of items grows, the number of batches grows roughly in proportion.
| Input Size (n) | Approx. Batch Requests |
|---|---|
| 10 | 1 batch (no retries if all succeed) |
| 100 | 4 batches (each up to 25 items) |
| 1000 | 40 batches |
Pattern observation: The number of batch requests grows linearly with input size, but retries can add extra requests depending on unprocessed items.
Time Complexity: O(n)
This means the total time grows roughly in direct proportion to the number of items being processed.
[X] Wrong: "Batch writes always complete in a single request regardless of input size."
[OK] Correct: DynamoDB limits batch writes to 25 items per request, and unprocessed items cause retries, so multiple requests are needed as input grows.
Understanding how batch limits and retries affect performance shows you can handle real-world API constraints and design efficient data operations.
"What if the batch size limit changed from 25 to 50? How would the time complexity change?"
Practice
Solution
Step 1: Understand batch write limits
DynamoDB limits batch write operations to a maximum of 25 items per request to avoid overloading the service.Step 2: Reason about the purpose of limits
These limits help prevent throttling and ensure stable performance by controlling request size.Final Answer:
To prevent sending too many items at once and avoid throttling -> Option CQuick Check:
Batch limits = prevent throttling [OK]
- Thinking batch limits increase item size
- Assuming retries are automatic without checks
- Confusing batch limits with table count
BatchWriteItem request in DynamoDB?Solution
Step 1: Recall DynamoDB batch write limits
DynamoDB allows a maximum of 25 items perBatchWriteItemrequest.Step 2: Compare options with the limit
Only 25 items matches the correct limit of 25 items.Final Answer:
25 items -> Option AQuick Check:
BatchWriteItem max = 25 items [OK]
- Choosing 50 or 100 items which exceed the limit
- Confusing batch write with batch get limits
- Assuming 10 items is the max without checking docs
response = client.batch_write_item(RequestItems={
'MyTable': [
{'PutRequest': {'Item': {'ID': {'S': '1'}}}},
{'PutRequest': {'Item': {'ID': {'S': '2'}}}}
]
})
print(response.get('UnprocessedItems'))
If the response prints {}, what does it mean?Solution
Step 1: Understand UnprocessedItems meaning
TheUnprocessedItemskey contains items that DynamoDB did not process and need retrying.Step 2: Interpret empty dictionary response
An empty dictionary{}means no unprocessed items, so all were processed successfully.Final Answer:
All items were processed successfully with no retries needed -> Option DQuick Check:
Empty UnprocessedItems = all processed [OK]
- Assuming empty means failure
- Thinking only partial items processed
- Confusing batch limits with processing status
Solution
Step 1: Identify batch write limit violation
DynamoDB batch write limits max 25 items per request, so 30 items exceed this limit.Step 2: Apply correct fix by splitting batches
Splitting into two batches (25 and 5) respects the limit and avoids errors.Final Answer:
Split the 30 items into two batches of 25 and 5 items -> Option AQuick Check:
Split batches to respect 25 item limit [OK]
- Trying to send all items at once ignoring limits
- Using batch get which is for reads, not writes
- Reducing item size does not fix batch count limit
Solution
Step 1: Understand unprocessed items cause
Unprocessed items occur when DynamoDB throttles requests; these items need retrying.Step 2: Apply best retry strategy
Retry only unprocessed items with exponential backoff to avoid repeated throttling and ensure eventual success.Final Answer:
Immediately retry only the unprocessed items with exponential backoff -> Option BQuick Check:
Retry unprocessed items with backoff [OK]
- Ignoring unprocessed items causing data loss
- Retrying entire batch wastes resources
- Increasing batch size worsens throttling
Ready to prove it?
Pass the test and this pattern moves unknown
