A company has an automobile sales website that stores its listings in a database on Amazon RDS. When an automobile is sold, the listing needs to be removed from the website and the data must be sent to multiple target systems.
Which design should a solutions architect recommend?
To ensure that the data is sent to multiple target systems after an automobile listing is removed from the website, the best approach is to use an AWS Lambda function that is triggered when the database on Amazon RDS is updated. This Lambda function can then send the relevant information to an Amazon Simple Queue Service (SQS) queue, from which the target systems can consume the messages. This design leverages Lambda for processing and SQS for message queuing, allowing decoupling and scalable consumption by multiple targets. Using an SQS queue allows multiple consumers to read the messages, thereby facilitating the distribution of the information to multiple target systems.
Interesting point that Amazon RDS event notification doesn't support any notification when data inside DB is updated. https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Events.overview.html So subscription to RDS events doesn't give any value for Fanout = SNS => SQS B is out because FIFO is not required here. A is left as correct answer
D is connect RDS event notification by RDS stream or advance audit DML so it is possible
The key is "Fanned out" due to "Multiple target systems" need to update
Please provide reference for this claim: " event notification by RDS stream or advance audit DML"
Listing the Amazon RDS event notification categories. https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Events.ListingCategories.html:
I don't think A is a valid solution ... how do you send the data to multiple targets using a single SQS?
But... SQS is a queue and is incapable of sending messages to "multiple target systems". SNS is pub/sub and topics can be subscribed by multiple apps to update when such an even occurs. Moreover Amazon RDS uses native capabilities of DBs like Postgres, MS SQL for change data capture. This can be used to send notifications to SNS
RDS events only provide operational events such as DB instance events, DB parameter group events, DB security group events, and DB snapshot events. What we need in the scenario is to capture data-modifying events (INSERT, DELETE, UPDATE) which can be achieved thru native functions or stored procedures.
I agree with it requiring a native function or stored procedure, but can they in turn invoke a Lambda function? I have only seen this being possible with Aurora, but not RDS - and I'm not able to find anything googling for it either. I guess it has to be possible, since there's no other option that fits either. https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Integrating.Lambda.html
To add to that though, A also states to only use SQS (no SNS to SQS fan-out), which doesn't seem right as the message needs to go to multiple targets?
D is the right option When asked Amazon Q: Can I create an event notification for a delete row action for a table in the RDS Database? The answer was: Yes, it is possible to create an event notification for delete row actions in an RDS database table. When a row is deleted from an RDS database table, it will trigger a "Delete" event. You can subscribe to these events by creating an Amazon RDS event notification subscription. Hence, for the remaining architecture, D is the best way forward.
To sum up: There seems to be sth wrong with this question. D: Sounds plausible, but RDS events only provide operational events, e.g. shutdown, failover, config change. C: see D, also makes no sense since fanout is SNS -> SQS B: No mention of FIFO requirement. A: Invoking an AWS Lambda function is possible, albeit only from Postgres-flavored RDS[1]. However, this solution lacks fanout architecture (SNS -> multiple SQS) to enable multiple consumers as required. [1] https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/PostgreSQL-Lambda.html
D could have been a perfect solution but RDS does not create event notifications based on database updates .. You can refer to the link below to the kind of events RDS triggers notifications for => https://dzone.com/articles/how-can-i-know-what-happens-inside-amazon-rds#:~:text=an%20event%20subscription.-,AWS%20RDS%20Event%20Categories%20and%20Messages,-Amazon%20RDS%20generates A is a good alternative that lacks fanning out which will not be necessary if the visibility timeout is adjusted properly and the targets are not many. A is the near best alternative so I GO in for A.
I am not sure why the folks who selected A don't select B instead. Given that this is basically e-commerce, you would want the action to be processed "exactly once" (i.e. you can only sold a car once). In that case, FIFO will give "exactly once" behavior over standard, so you don't accidentally carry out an action multiple times for the same sale.
Exactly
RDS events only provide operational events such as DB instance events, DB parameter group events, DB security group events, and DB snapshot events. What we need in the scenario is to capture data-modifying events i.e delete. Usually, you can do it through a native function or stored procedure
AWS RDS Event Categories and Messages Amazon RDS generates several different events. The key event categories include : DB instance created/deleted/restarted/shutdown Maintenance , patching , backup & Recovery Configuration changes, snapshot actions https://dzone.com/articles/how-can-i-know-what-happens-inside-amazon-rds
Wouldn't we want to process orders in FIFO manner?
Why should we?
If you understood FIFO you would ask that question.
From language perspective A looks better than D but the implementation in D is much closer to what A should be. It is confusing either way.
Fanout->SNS->SQS
Option A: Triggering a Lambda function directly from RDS updates isn't straightforward without using an intermediary service like SNS or SQS to handle the messaging. Option B: While SQS FIFO queues ensure order, they aren't necessary unless the application requires strict order in processing sales data, and they don't inherently support multiple targets without additional configuration. Option C: RDS event notifications typically signal RDS instance events (like backups or maintenance) rather than data-level changes within the database.
Answer is C , multiple subscribers.
The most suitable design for the scenario described is: D. Subscribe to an RDS event notification and send an Amazon Simple Notification Service (Amazon SNS) topic fanned out to multiple Amazon Simple Queue Service (Amazon SQS) queues. Use AWS Lambda functions to update the targets. This design leverages RDS event notifications to trigger a fan-out mechanism through Amazon SNS. Subsequently, AWS Lambda functions can be used to process these messages and update the multiple target systems efficiently. This approach allows for decoupling the components and provides flexibility in managing the integration with different target systems.
RDS event notification doesn't support any notification
confuse with A and D as both violate one of the another. But Options D looks more appropriate to fan out to multiple targets using SNS
I can't understand why people are opting for A but not B. Using a standard SQS queue (non-FIFO) does not guarantee message order and can lead to potential duplicate processing if not handled carefully. This might not be suitable when precise order and exactly-once processing are required, as in the case of removing automobile listings and sending data to multiple systems simultaneously.