Exam AWS Certified Solutions Architect - Associate SAA-C03 topic 1 question 108 discussion

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

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.

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.

A for sure

You have to fan out first with SNS

The best design is **D. Subscribe to an RDS event notification and send an Amazon SNS topic fanned out to multiple Amazon SQS queues. Use AWS Lambda functions to update the targets**. - **SNS fan-out** enables sending data to multiple SQS queues for different target systems. - **Lambda** can process messages from each SQS queue and update the targets. ### Why not others: - **A** and **B**: No fan-out mechanism, making it harder to deliver to multiple targets. - **C**: Reverses the typical fan-out pattern (SQS to SNS) and is less efficient. Option D offers better scalability and decoupling.

A and C cannot be correct: "an (one) SQS queue for the targets (multiple) to consume". "an (one) SQS queue fanned out to multiple SNS" That would be one-to-many relationship, which is not supported by SQS. "SQS has a many-to-one relationship. You can send messages to a queue from many different producers but only one consumer can be defined." https://blog.awsfundamentals.com/aws-sns-vs-sqs-what-are-the-main-differences#heading-many-to-many-vs-many-to-one-number-of-consumers

Answer is D, this is a typical scenario for SQS fan-out. A can not send data to multiple targets

Ans C - using SQS means events are time-order preserved and then can be sent to multiple consumers using SNS

https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_OpenSearch_Stream.html

RDS Event Notification: Amazon RDS supports event notifications, which can trigger actions when specific events occur, such as a record update or delete operation. In this case, an event would be triggered when a listing is removed. Amazon SNS: SNS allows the event to be published to a topic that can then be fanned out to multiple SQS queues. This is useful when you have multiple target systems that need to receive the data. SNS can push the message to all subscribed SQS queues simultaneously. Amazon SQS: SQS provides reliable message queuing. Each target system can consume messages from its respective SQS queue at its own pace, ensuring that no messages are lost. AWS Lambda: Lambda functions can be triggered by the SQS queues to process the messages and update the target systems accordingly. This approach allows for asynchronous processing and decouples the RDS update from the target system updates, improving scalability and reliability.

Fan out needs SNS

Why not answer (B) because the car sold first should be updated on the target system first so that more than one customers cannot purchase the same car

Fan-out pattern chose D

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.

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 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.