Stream processing patterns in DynamoDB - Time & Space Complexity
When working with DynamoDB streams, it is important to understand how processing time changes as more data flows through the stream.
We want to know how the time to handle stream records grows as the number of records increases.
Analyze the time complexity of the following DynamoDB stream processing code.
// Pseudocode for processing DynamoDB stream records
function processStreamRecords(records) {
for (const record of records) {
if (record.eventName === 'INSERT') {
// Process new item
handleInsert(record.dynamodb.NewImage);
} else if (record.eventName === 'MODIFY') {
// Process updated item
handleModify(record.dynamodb.NewImage);
}
}
}
This code loops through each stream record and processes it based on the event type.
Look at what repeats as the input grows.
- Primary operation: Looping through each stream record once.
- How many times: Once per record in the stream batch.
As the number of records increases, the processing time grows proportionally.
| Input Size (n) | Approx. Operations |
|---|---|
| 10 | 10 processing steps |
| 100 | 100 processing steps |
| 1000 | 1000 processing steps |
Pattern observation: Doubling the number of records roughly doubles the work done.
Time Complexity: O(n)
This means the time to process stream records grows directly with the number of records.
[X] Wrong: "Processing one record takes constant time, so processing many records is still constant time overall."
[OK] Correct: Each record requires its own processing step, so more records mean more total work.
Understanding how stream processing scales helps you design systems that handle growing data smoothly and reliably.
"What if we batch process records in groups instead of one by one? How would the time complexity change?"
Practice
Solution
Step 1: Understand DynamoDB Streams role
DynamoDB Streams capture data changes like inserts, updates, and deletes as they happen.Step 2: Identify the purpose in stream processing
Streams allow applications to react immediately to these changes, enabling real-time processing.Final Answer:
To capture and react to data changes in real time -> Option AQuick Check:
Streams = real-time data reaction [OK]
- Confusing Streams with data storage
- Thinking Streams create backups
- Assuming Streams speed up queries
Solution
Step 1: Recall how to enable Streams
Streams are enabled by setting the StreamSpecification property on the table with StreamEnabled set to true and choosing a StreamViewType.Step 2: Evaluate options
Set StreamSpecification with StreamEnabled = true and StreamViewType correctly describes enabling Streams. The other options do not enable Streams properly.Final Answer:
Set StreamSpecification with StreamEnabled = true and StreamViewType -> Option CQuick Check:
Enable Streams via StreamSpecification [OK]
- Trying to enable Streams via Lambda triggers
- Confusing Streams with indexes
- Using UpdateItem API to enable Streams
Solution
Step 1: Understand StreamViewType NEW_IMAGE
NEW_IMAGE means the stream records contain the item as it appears after the change.Step 2: Determine what Lambda receives on update
Lambda gets the new item image only, not the old one or both.Final Answer:
Only the new item image after the update -> Option BQuick Check:
NEW_IMAGE = new item data only [OK]
- Confusing NEW_IMAGE with OLD_IMAGE or BOTH_IMAGES
- Expecting both old and new images
- Assuming keys only are sent
Solution
Step 1: Check Stream enablement
If Streams are not enabled on the table, no events trigger Lambda.Step 2: Evaluate other options
Syntax errors cause failures but do not prevent invocation. No data means no changes, but usually there are some. Timeout too long does not stop invocation.Final Answer:
The DynamoDB table does not have Streams enabled -> Option AQuick Check:
Streams must be enabled for Lambda triggers [OK]
- Assuming code errors stop Lambda from triggering
- Ignoring Streams enablement
- Thinking timeout affects event triggering
Solution
Step 1: Understand the need to detect attribute changes
To detect changes in "status", you need both old and new values to compare.Step 2: Choose the right pattern
Filtering and transforming stream records in Lambda lets you compare old and new images and trigger notifications only on "status" changes.Step 3: Evaluate other options
OLD_IMAGE alone lacks new data, KEYS_ONLY lacks attribute data, polling is inefficient and not real-time.Final Answer:
Filter and transform stream records in Lambda to detect "status" changes -> Option DQuick Check:
Filter stream records in Lambda for attribute changes [OK]
- Using KEYS_ONLY which lacks attribute data
- Relying on OLD_IMAGE without new data
- Polling instead of using Streams
Ready to prove it?
Pass the test and this pattern moves unknown
