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

D makes more sense to me.

Keywords: - The number of messages varies drastically - Sometimes increases suddenly to 100,000 each second A: Incorrect - Don't confuse between Kinesis Data Analytics and Kinesis Data Stream =)) Kinesis Data Analytics will get the data from Kinesis Data Stream or Kinesis Data FireHose or MSK (Managed Stream for apache Kafka) for analytic purpose. It can not consume message and send to applications. B: Incorrect - Base on the keywords -> Auto Scaling group not scale well because it need time to check the CPU metric and need time to start up the EC2 and the messages varies drastically. Example: we have to scale from 10 to 100 EC2. Our servers may be down a while when it was scaling. C: Incorrect - Kinesis Data Streams can handle this case but we should increase the more shards but not single shard. D: Correct: We can handle high workload well with fan-out pattern SNS + multiple SQS -> This is good for use case: - The number of messages varies drastically - Sometimes increases suddenly to 100,000 each second

The other options are not correct. Like Option A: Kinesis Data Analytics is designed for real-time data processing and analytics. Not for message queuing and decoupling.

D is correct answer

using an SQS queues to decouple this soluton will be the best approach since an SQS queue is very scalable and the number of messages to scale can be incremented by the user manually or by the use of security groups

I choose D because the question say "decouple/scalable" and the best services for that are SNS/SQS.

D should be the answer as it is achieving a good decoupling: 1. Use SNS to create topics so messages for different applications will go on different topics 2. Create multiple SQS queues and subscribe to different SNS topics and let the different applications poll from their related SQS qeueus.

Amazon SNS + SQS provides a scalable and decoupled architecture: SNS is a publish-subscribe messaging service that allows the ingestion application to broadcast messages to multiple subscribers. SQS acts as the subscriber to the SNS topic, creating separate message queues for each consumer application. This ensures: Scalability: Messages are distributed across queues, decoupling the producer and consumers. Reliability: SQS queues store messages until consumer applications can process them, accommodating sudden spikes in message volume.

D is correct, and the easiest way to choose this answer choice is by the keyword "decouple." In order to decouple services, you can choose to use SQS/SNS (I believe there is a typo that says SOS)

The Correct Answer is D because it is required loosely couple and distributed queing system apporach.

***CORRECT ANSWER*** The correct solution that meets these requirements is Option D: Publish the messages to an Amazon Simple Notification Service (Amazon SNS) topic with multiple Amazon Simple Queue Service (Amazon SQS) subscriptions. Configure the consumer applications to process the messages from the queues. Option D involves using Amazon Simple Notification Service (SNS) and Amazon Simple Queue Service (SQS) to decouple the solution and increase scalability. SNS is a fully managed, publish-subscribe messaging service that allows you to send messages to multiple recipients simultaneously. SQS is a fully managed, distributed message queue service that enables you to store, process, and transmit messages between microservices, distributed systems, and serverless applications.

SNS and SQS still have an standard limit of tails under 3000 messages per sec, because SNS and SQS still have an standard limit of tails under 3000 messages per sec. It does not accomplishes with the requirement. Perharps it's a possible solution: Amazon Kinesis Data Analytics. Configure the consumer applications to read and process the messages, but it requires that change the arch of this app, but this point is no matter on ther requirement.

Option A: It is more suitable for real-time analytics and processing of streaming data rather than decoupling and scaling message ingestion and consumption. Option B: It may help with scalability to some extent, but it doesn't provide decoupling. Option C: It is a valid option, but it lacks the decoupling aspect. In this approach, the consumer applications would still need to read directly from DynamoDB, creating tight coupling between the ingestion and consumption processes. Option D: It is the recommended solution for decoupling and scalability. The ingestion application can publish messages to an SNS topic, and multiple consumer apps can subscribe to the relevant SQS queues. SNS ensures that each message is delivered to all subscribed queues, allowing the consuming apps to independently process the messages at their own pace and scale horizontally as needed. This provides loose coupling, scalability, and fault tolerance, as the queues can handle message spikes and manage the consumption rate based on the consumer's processing capabilities.

The answer is D. Publish the messages to an Amazon Simple Notification Service (Amazon SNS) topic with multiple Amazon Simple Queue Service (Amazon SQS) subscriptions. Configure the consumer applications to process the messages from the queues. This solution is the most scalable and decoupled solution for the given scenario. Amazon SNS is a pub/sub messaging service that can be used to decouple applications. Amazon SQS is a fully managed message queuing service that can be used to store and process messages. The solution would work as follows: The ingestion application would publish the messages to an Amazon SNS topic. The Amazon SNS topic would have multiple Amazon SQS subscriptions. The consumer applications would subscribe to the Amazon SQS queues. The consumer applications would process the messages from the Amazon SQS queues.

D. is the answer. The question states that there are dozens of other applications and microservices that consume these messages and that the volume of messages can vary drastically and increase suddenly. Therefore, you need a solution that can handle a high volume of messages, distribute them to multiple consumers, and scale quickly. SNS with SQS provides these capabilities. Publishing messages to an SNS topic with multiple SQS subscriptions is a common AWS pattern for achieving both decoupling and scalability in message-driven systems. SNS allows messages to be fanned out to multiple subscribers, which in this case would be SQS queues. Each consumer application could then process messages from its SQS queue at its own pace, providing scalability and ensuring that all messages are processed by all consumer applications. A. Amazon Kinesis Data Analytics is primarily used for real-time analysis of streaming data. It's not designed to distribute messages to multiple consumers.

Option D Amazon SNS allows you to publish messages to a topic, which can then fan out those messages to multiple subscribers. By using Amazon SQS as a subscriber to the SNS topic, you can handle the message load in a decoupled and scalable way. SQS can store messages until the consuming application is ready to process them, helping to smooth out the variance in message load. This approach allows the company to effectively decouple the message producing applications from the consuming applications, and it can easily scale to handle the high load of messages. The number of messages (100,000 each second) might require careful configuration and sharding of SQS queues or use of FIFO queues to ensure that they can handle the load. Options A, B, and C have their own limitations:

D. Here’s why option D is the correct choice: Amazon SNS: Amazon SNS is a fully managed pub/sub messaging service that enables message publishing and subscription to topics. It provides fast and flexible communication between publishers and subscribers. Amazon SQS: Amazon SQS is a fully managed message queuing service that decouples the components of a distributed application. It offers reliable and scalable queues for storing messages and enables applications to process them asynchronously. By publishing the messages to an Amazon SNS topic and using Amazon SQS subscriptions, the solution achieves decoupling and scalability. Multiple applications and microservices can subscribe to the topic and receive messages through their individual SQS queues. This allows for parallel processing and enables the system to handle varying message volumes, including spikes of up to 100,000 messages per second.