Scan pagination in DynamoDB - Time & Space Complexity
Start learning this pattern below
Jump into concepts and practice - no test required
When we use scan pagination in DynamoDB, we want to understand how the time to get data grows as we ask for more pages.
We ask: How does the work increase when we read more pages of data?
Analyze the time complexity of the following code snippet.
let lastEvaluatedKey = null;
do {
const params = { TableName: "MyTable", Limit: 100 };
if (lastEvaluatedKey) {
params.ExclusiveStartKey = lastEvaluatedKey;
}
const data = await dynamodb.scan(params).promise();
lastEvaluatedKey = data.LastEvaluatedKey;
// process data.Items
} while (lastEvaluatedKey);
This code reads a DynamoDB table in pages of 100 items until all items are read.
Identify the loops, recursion, array traversals that repeat.
- Primary operation: Scanning a page of items from the table.
- How many times: Once per page, until all items are read.
Each page reads a fixed number of items (100). As the total items grow, the number of pages grows roughly proportionally.
| Input Size (n) | Approx. Operations (pages) |
|---|---|
| 10 | 1 (less than one full page) |
| 100 | 1 page |
| 1000 | 10 pages |
Pattern observation: The number of scan calls grows linearly with the total items.
Time Complexity: O(n)
This means the time to scan all items grows directly with how many items are in the table.
[X] Wrong: "Scan pagination time stays the same no matter how many items are in the table."
[OK] Correct: Each page reads a fixed number of items, so more items mean more pages and more scan calls, increasing total time.
Understanding how scan pagination scales helps you explain how to handle large datasets efficiently and shows you know how to reason about costs in real systems.
"What if we changed the page size from 100 to 1000? How would the time complexity change?"
Practice
Scan pagination in DynamoDB?Solution
Step 1: Understand Scan Pagination Concept
Scan pagination is used to divide a large scan operation into smaller chunks to avoid timeouts and manage resource use.Step 2: Identify the Purpose
The main goal is to process big scans in parts, not to speed writes or create indexes.Final Answer:
To break a large scan into smaller parts for easier processing -> Option DQuick Check:
Scan pagination = break large scan into parts [OK]
- Thinking pagination speeds up writes
- Confusing scan with index creation
- Assuming pagination deletes items
Solution
Step 1: Identify Pagination Parameters
In DynamoDB,LastEvaluatedKeyfrom the previous scan is used asExclusiveStartKeyto continue scanning.Step 2: Eliminate Incorrect Options
Limitsets chunk size, not start key.ScanIndexForwardis for queries, not scans.StartKeyis not a valid parameter.Final Answer:
Use LastEvaluatedKey as the ExclusiveStartKey in the next scan -> Option AQuick Check:
Continue scan = ExclusiveStartKey = LastEvaluatedKey [OK]
- Using Limit as ExclusiveStartKey
- Confusing scan with query parameters
- Using invalid parameter names
Limit is set to 5?response = table.scan(Limit=5)
items = response['Items']
last_key = response.get('LastEvaluatedKey')
print(len(items), last_key is not None)Solution
Step 1: Understand Limit Effect on Scan
SettingLimit=5returns up to 5 items in one scan call, not all 15.Step 2: Check LastEvaluatedKey Presence
Since there are more items after 5,LastEvaluatedKeywill be present (not None), indicating more data.Final Answer:
5 True -> Option CQuick Check:
Limit=5 returns 5 items and LastEvaluatedKey exists [OK]
- Assuming all items return ignoring Limit
- Expecting LastEvaluatedKey to be None always
- Confusing item count with total table size
response = table.scan(Limit=3)
items = response['Items']
while 'LastEvaluatedKey' in response:
response = table.scan(Limit=3)
items.extend(response['Items'])
print(len(items))What is the error?
Solution
Step 1: Analyze Pagination Loop
The loop calls scan repeatedly but does not passExclusiveStartKey, so it always scans from start.Step 2: Identify Missing Parameter
To continue scanning,ExclusiveStartKeymust be set to previousLastEvaluatedKeyin each call.Final Answer:
Missing ExclusiveStartKey in the subsequent scan calls -> Option AQuick Check:
Pagination needs ExclusiveStartKey to continue [OK]
- Not passing ExclusiveStartKey in loop
- Increasing Limit instead of fixing pagination
- Resetting items list inside loop
Solution
Step 1: Understand Pagination Requirements
To process 100 items at a time, scan must be done in chunks withLimit=100and continue usingExclusiveStartKey.Step 2: Evaluate Options
Use a loop withLimit=100and passExclusiveStartKeyfromLastEvaluatedKeyuntil no more keys correctly loops withLimit=100and usesExclusiveStartKeyfromLastEvaluatedKey. Scan once withLimit=1000and split results in code fetches all at once, risking timeout. UseScanIndexForward=truewithLimit=100to paginate uses wrong parameter for scan. SetExclusiveStartKeyto null and scan withLimit=100once scans only once without continuation.Final Answer:
Use a loop with Limit=100 and pass ExclusiveStartKey from LastEvaluatedKey until no more keys -> Option BQuick Check:
Paginate with Limit and ExclusiveStartKey loop [OK]
- Fetching all items at once risking timeout
- Using query parameters for scan
- Not looping to continue scan
