What should a solutions architect do to meet these requirements with the LEAST amount of operational overhead?
Use DynamoDB transactions to write new event data to the table. Configure the transactions to notify internal teams.
Have the current application publish a message to four Amazon Simple Notification Service (Amazon SNS) topics. Have each team subscribe to one topic.
Enable Amazon DynamoDB Streams on the table. Use triggers to write to a single Amazon Simple Notification Service (Amazon SNS) topic to which the teams can subscribe.
Add a custom attribute to each record to flag new items. Write a cron job that scans the table every minute for items that are new and notifies an Amazon Simple Queue Service (Amazon SQS) queue to which the teams can subscribe.
Explanations:
Using DynamoDB transactions to notify internal teams adds complexity and operational overhead. Transactions are not designed for asynchronous notifications and would impact performance as they are synchronous operations.
While publishing messages to multiple Amazon SNS topics could notify the teams, it requires the current application to be modified to handle message publishing, which could impact performance and adds unnecessary complexity.
Enabling DynamoDB Streams allows for real-time capture of changes in the database. By using AWS Lambda triggers, notifications can be sent to a single Amazon SNS topic without affecting the performance of the current application. This method minimizes operational overhead and ensures timely alerts.
Adding a custom attribute and using a cron job to scan the table introduces latency and operational complexity. Cron jobs can lead to delays in notifications and require more maintenance, making it less efficient compared to the event-driven architecture of DynamoDB Streams.
As I understand it, the answer is:
Enable Amazon DynamoDB Streams on the table. Use triggers to write to a single Amazon Simple Notification Service (Amazon SNS) topic to which the teams can subscribe.