Adjacency list pattern in DynamoDB - Time & Space Complexity
When working with the adjacency list pattern in DynamoDB, it's important to understand how the time to get connected items grows as the list grows.
We want to know how the number of operations changes when we fetch related nodes.
Analyze the time complexity of the following code snippet.
// Fetch all child nodes for a given parent node
const params = {
TableName: "GraphTable",
KeyConditionExpression: "ParentId = :pid",
ExpressionAttributeValues: {
":pid": { S: "parent123" }
}
};
const result = await dynamodb.query(params).promise();
return result.Items;
This code fetches all child nodes linked to a specific parent node using the adjacency list pattern.
Identify the loops, recursion, array traversals that repeat.
- Primary operation: Querying DynamoDB to get all children of one parent.
- How many times: Once per parent node, but returns multiple child items.
As the number of children for a parent grows, the query returns more items, so the work grows with the number of children.
| Input Size (n = number of children) | Approx. Operations |
|---|---|
| 10 | About 10 items fetched |
| 100 | About 100 items fetched |
| 1000 | About 1000 items fetched |
Pattern observation: The time grows roughly in direct proportion to the number of children returned.
Time Complexity: O(n)
This means the time to get all children grows linearly with how many children there are.
[X] Wrong: "Querying a parent node always takes constant time regardless of children count."
[OK] Correct: The query returns all children, so if there are many children, it takes longer to fetch and process them all.
Understanding how data retrieval time grows with connected items helps you design efficient queries and explain your choices clearly in interviews.
"What if we added pagination to limit the number of children returned per query? How would the time complexity change?"
Practice
Solution
Step 1: Understand adjacency list pattern basics
The adjacency list pattern stores a reference to the parent item for each node to represent hierarchy.Step 2: Identify what is stored per item
Each item contains the parent's ID, not the children or full path or depth.Final Answer:
The parent item's identifier -> Option AQuick Check:
Adjacency list = parent ID stored [OK]
- Thinking it stores all children in each item
- Confusing with storing full path or depth
- Assuming it stores unrelated metadata
Solution
Step 1: Identify adjacency list item structure
Adjacency list stores the parent ID inside each item to link it to its parent.Step 2: Match correct JSON structure
{ "ItemId": "123", "ParentId": "456" }shows an item with its own ID and a ParentId field, which is correct.Final Answer:
{ "ItemId": "123", "ParentId": "456" } -> Option BQuick Check:
ParentId field present = adjacency list format [OK]
- Using Children array instead of ParentId
- Including full path or depth instead of parent reference
- Confusing item ID with parent ID
{ "ItemId": "1", "ParentId": null }{ "ItemId": "2", "ParentId": "1" }{ "ItemId": "3", "ParentId": "1" }{ "ItemId": "4", "ParentId": "2" }If you query for items with
ParentId = '1', which items will you get?Solution
Step 1: Understand query condition
The query filters items where ParentId equals '1'.Step 2: Identify matching items
Items with ParentId '1' are ItemId '2' and '3'. Item '4' has ParentId '2', so it does not match.Final Answer:
[{ "ItemId": "2", "ParentId": "1" }, { "ItemId": "3", "ParentId": "1" }] -> Option AQuick Check:
Filter ParentId='1' returns items 2 and 3 [OK]
- Including items with different ParentId values
- Confusing root item with children
- Assuming query returns grandchildren
FilterExpression: "ParentId = :pid", ExpressionAttributeValues: { ":pid": "5" }But it returns no results, even though you know children exist. What is the likely error?
Solution
Step 1: Check attribute naming
If ParentId attribute is missing or named differently, filter finds no matches.Step 2: Verify attribute presence in items
Ensure all child items have ParentId attribute exactly named 'ParentId'. If not, query returns empty.Final Answer:
ParentId attribute is missing or named differently in items -> Option DQuick Check:
Attribute name mismatch causes no results [OK]
- Confusing FilterExpression with KeyConditionExpression
- Incorrect syntax in ExpressionAttributeValues
- Querying by ItemId instead of ParentId
Solution
Step 1: Understand adjacency list limitations
Adjacency list stores only parent references, so full path is not stored.Step 2: Retrieve full path by iterative queries
To get full path, query each item's parent repeatedly until root (ParentId null) is reached.Step 3: Evaluate other options
Store the full path string in each item and query it directly is a different pattern (materialized path). Use a single query filtering all items with ParentId equal to the child's ID gets children, not parents. Use a DynamoDB join operation to combine parent and child items is invalid as DynamoDB has no join.Final Answer:
Iteratively query each item's ParentId until reaching the root -> Option CQuick Check:
Adjacency list needs iterative parent queries for full path [OK]
- Expecting DynamoDB to support joins
- Assuming full path is stored in adjacency list
- Trying to get full path with single query filtering children
Ready to prove it?
Pass the test and this pattern moves unknown
