A team wants to automatically send a notification whenever a new order item is inserted into a DynamoDB table, without polling the table on a schedule. The change should be captured and processed within seconds of the write, and it is acceptable if very old, unprocessed changes eventually become unavailable. Which approach fits?
- Query the table every few seconds using a scheduled EventBridge rule and diff the results
- Enable DynamoDB Streams on the table and configure a Lambda function as a trigger to process each stream record
- Enable RDS event notifications on the table
- Use a DynamoDB global secondary index and subscribe to it via SNS
Why B? And why not the others?
Correct answer: B. Enable DynamoDB Streams on the table and configure a Lambda function as a trigger to process each stream record
DynamoDB Streams captures a time-ordered, near-real-time log of item-level changes, including inserts, updates, and deletes, and can invoke a Lambda function automatically for each batch of stream records, which is the standard event-driven pattern for reacting to writes without polling; stream records are retained for 24 hours and are subject to trimming after that, matching the acceptance that very old unprocessed changes can become unavailable. The option describing a scheduled EventBridge query is wrong because polling on an interval is exactly the pattern the requirement rules out, and it introduces both latency and unnecessary read costs. The option describing RDS event notifications is wrong because RDS event notifications report operational events about a relational database instance, such as failovers or backups, not item-level data changes in a DynamoDB table, which is a separate service entirely. The option describing subscribing to a global secondary index via SNS is wrong because secondary indexes are a query mechanism for existing data and have no built-in mechanism to publish change notifications to SNS.
Source: AWS DynamoDB documentation: change data capture with DynamoDB Streams