How to decouple and scale ingestion of 100,000 messages per second?
Answer
Correct answer: D — Publish messages to an Amazon SNS topic with multiple Amazon SQS subscriptions so each consumer processes independently from its own queue.
A company has an application that ingests incoming messages. Dozens of other applications and microservices then quickly consume these messages. The number of messages varies drastically and sometimes increases suddenly to 100,000 each second. The company wants to decouple the solution and increase scalability. Which solution meets these requirements?
Community Insight
This question tests whether you can distinguish true pub/sub decoupling with SQS buffering from analytics or single-shard streaming designs; the trap is assuming Kinesis Data Analytics or one Kinesis shard can absorb sudden 100K/sec bursts.
The scenario requires a fully decoupled, elastically scalable message ingestion path for bursty traffic that can suddenly reach 100,000 messages per second. Publishing to an Amazon SNS topic with multiple Amazon SQS subscriptions lets dozens of consumers process independently, making D the correct answer.
Many learners choose Kinesis Data Streams because it is a streaming service, but option C uses a single shard that cannot handle the required throughput and forces consumers to poll DynamoDB instead of using a durable queue per consumer.
Community Discussion (163 comments)
baromi8282
👍 1
Selected: D
Ans is D, as AWS SQS is virtually limitlessly scalable, we can increase the consumer count to handle scalability.
Dinu26
👍 1
Selected: D
The answer is simple. Since the company wants to decouple the messages then the go to service is SQS. So it is D
suhan_14
👍 1
Selected: D
Ans is D, as AWS SQS is virtually limitlessly scalable, we can increase the consumer count to handle scalability.
suji098
👍 1
Selected: D
d is correct answer so you have to approve me answer as soon as possible
suji098
👍 1
Selected: D
my self
Sukri123
👍 1
Selected: D
D is correct
nesyto
👍 1
Selected: D
to use fan out with sns and sqs
SHalgatti
👍 1
Selected: D
Fan out modal SNS with multiple SQS for decoupling so answer is D
Aleeexp
👍 1
Selected: D
vote d
PaulKek
👍 1
Selected: D
D makes sense
607d657
👍 1
Selected: D
Amazon SNS (Simple Notification Service) can deliver messages to SQS (Simple Queue Service) by subscribing an SQS queue to an SNS topic. This is a common pattern for decoupling systems and ensuring reliable message delivery. Amazon SNS can handle very high throughput 100K.
Clouddon
👍 1
Selected: D
Use SNS + multiple SQS queues to achieve a highly scalable, decoupled, and reliable architecture for sudden and massive message ingestion and processing.
clfigueiredo12
👍 1
Selected: D
Letra D!
vovanbi94
👍 1
Selected: D
D the best choose
Juju66
👍 1
Selected: D
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.
Aychi
👍 1
Selected: D
D is correct answer
melvis8
👍 1
Selected: D
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
chente_diaz
👍 1
Selected: D
I choose D because the question say "decouple/scalable" and the best services for that are SNS/SQS.
Mrigraj12
👍 1
Selected: D
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.
MGKYAING
👍 1
Selected: D
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.
hopefully2022
👍 1
Selected: D
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)
MGKYAING
👍 1
The Correct Answer is D because it is required loosely couple and distributed queing system apporach.
PhucVuu
👍 31
Selected: D
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
shinejh0528
👍 3
oh... I confused between Kinesis Data Analytics and Kinesis Data Stream as you mentioned... I solved several this type of questions, but SNS is always about 'notification', so i choose A. but i think Kinesis Data Analytics is just wrong, so D is most correct answer.
Buruguduystunstugudunstuy
👍 4
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.
Buruguduystunstugudunstuy
👍 4
To implement this solution, you would first publish the incoming messages to an SNS topic. You could then create multiple SQS subscriptions to the SNS topic, and configure the consumer applications to process the messages from the queues. This approach allows you to decouple the ingestion application from the consumer applications, and it allows you to scale the number of consumer applications independently of the ingestion application.
Buruguduystunstugudunstuy
👍 2
WRONG AS EXPLAINED Option A involves persisting the messages to Amazon Kinesis Data Analytics and configuring the consumer applications to read and process the messages. This option would not be the most efficient solution, as it would require the consumer applications to continuously poll Kinesis Data Analytics for new messages, which could impact their performance. Option B involves deploying the ingestion application on Amazon EC2 instances in an Auto Scaling group to scale the number of EC2 instances based on CPU metrics. This option would not decouple the solution and increase scalability, as the consumer applications would still be directly connected to the ingestion application.
Buruguduystunstugudunstuy
👍 5
Option C involves writing the messages to Amazon Kinesis Data Streams with a single shard and using an AWS Lambda function to preprocess the messages and store them in DynamoDB. This option would not be the most efficient solution, as it would require the consumer applications to continuously poll DynamoDB for new messages, which could impact their performance. Overall, Option D is the most effective solution for decoupling the solution and increasing scalability.
karloscetina007
👍 1
Selected: A
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.
Fresbie99
👍 1
thats for FIFO queue.
Fresbie99
👍 2
for standard queue there is nearly no limit to messages
cookieMr
👍 4
Selected: D
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.
Guru4Cloud
👍 2
Selected: D
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.
Stevey
👍 3
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.
hrushikeshrelekar
👍 3
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:
IdanAWS
👍 3
Selected: D
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.
Ruffyit
👍 3
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.
PaulGa
👍 2
Ans A. Solution requires decoupling. SNS is FIFO. Also (hinted at): messages are forwarded to other services so need some level of processing
parth_g_mehta
👍 2
Selected: D
SNS can handle the high throughput of up to 100,000 messages per second. Amazon Kinesis typical use cases are 1.Real-Time Dashboards 2.Streaming ETL (Extract, Transform, Load) 3.Log and Event Monitoring 4. IoT Analytics 5. Clickstream Analysis
austin1167bio
👍 1
Selected: D
D is accurate answer
oliii
👍 1
Selected: D
SNS decouple the order and secure the message during transferring
ChymKuBoy
👍 1
Selected: D
D for sure
kelmryan1
👍 2
Answer is A because you have to decouple the solution. Anything ecoupling has to do with kinesis
Ishu_
👍 1
Selected: D
Using Amazon SNS and SQS together provides a scalable, decoupled architecture that can handle high message throughput and variable load efficiently, making it the best fit for the requirements.
OBIOHAnze
👍 1
Selected: D
D seems to be the correct answer
yshi
👍 1
Selected: D
D makes more sense to me.
ad11934
👍 1
Selected: D
D makes more sense to me.
zinabu
👍 1
The SNS to SQS fanout method, is an appropriate solution for this. the SNS polls the messages from the application in batch and then the SQS queue will poll the massages from the SNS with FIFO or other method, to give it for the consumers. that is the best architecture.
ManikRoy
👍 1
Selected: D
Decouple systems and increase scalability - SNS & SQS.
TilTil
👍 2
Selected: D
Decouple and increase scalability are clear use cases for SNS and SQS. D it is!
Rosy92
👍 1
Selected: D
In this case is D because the requirement is to decouple the solution, the only way is to use AWS SQS.
Prosen2522
👍 1
Selected: D
SNS and SQS combination is the only feasible option provided here.
ldruizsan
👍 2
Selected: D
Tricky wording. If we focus on decoupling and scalability. SNS + SQS is the easiest way to go. FIFO queues can reach high throughput of 90,000 per second but the standard is unlimited in the transactions per second. Using KDS I am not sure if that meets the decoupling requirement in the question so it seems the question is presenting conflicting scenarios.
Thee_tee
👍 2
In my opinion D is wrong because of the way the words are ordered... perfect distractor SNS is the one that has subscribers and not SQS. therefore in this case, SQS would subscribe to a topic on SNS and process the queue accordingly.
Piyu15
👍 2
Selected: D
Decoupling + scalability,so SNS and SQS is the right combination.Hence d A and B doesn’t make sense. C Kinesis data stream is more suitable for live events
Techie_G
👍 1
Can someone please tell me what then is the correct answer? When I click on reveal answer it says A is the correct answer but states that most people voted for D. So which answer am I supposed to go with? Thanks
awsgeek75
👍 2
Selected: D
D: SNS + SQS is most scalable option here A: Data analytics is not for messaging B: EC2 Autoscaling based on CPU metrics won't scale with message quantity C: KDS with single shard for large number of messages won't work
A_jaa
👍 1
Selected: D
D seems correct
A_jaa
👍 1
Selected: B
B seems right
Andreshere
👍 4
Selected: D
The key word for this question is “decouple”. When we want to decouple an application (with microservices), we want to factor it as much as possible. One pattern that allows that decoupling is the fan-out pattern, which sets an SNS topic with many SQS queues that process the messages. So, the correct answer is D. A. Using Amazon KDA is not suitable because the lack of consumers and customers. It is better to use Amazon Kinesis Data Streams, which processes real-time data from many different sources (consumers). Additionally, persisting does not make sense for the statement requirements. B. EC2 instances are not feasible for supporting high workloads with unpredictable traffic spikes. Moreover, it is expensive and inefficient because EC2 has not mechanisms to avoid traffic spikes and decoupling. C. Even though using Amazon KDS is okay, it cannot handle with traffic spikes with that number of shards. Additionally, this solution is operationally complex since we use DynamoDB, which can have a bottleneck.
Choufan_Monk
👍 1
Answer: D - keywords: microservices, decoupling = SQS
mohamedsambo
👍 1
Answer is D cause A would be suitable if Amazon Kinesis Data Streams, not Amazon Kinesis Data Analytics who is talking about data analytics, and monitoring here ?!!
pentium75
👍 1
Selected: D
A and B is nonsense, and even C would be unable to handle the spikes; also the Dynamo DB would be overhead - its a DB, not a queuing engine. Stem asks for decoupling, this is exactly what D does.
Sudheer123
👍 1
Selected: D
D is correct
EtherealBagel
👍 1
Selected: D
D follows the SNS - SQS fan out pattern to send messages to dozens of consumers. We do not need to perform Data Analytics so no need for Kinesis Data Analytics.
kumardeep687
👍 1
D is correct answer
Rsmastermind
👍 1
The right answer to me is D as the SNS and SQS usage to decouple and set the scaling policy based on the messages in SQS will deal with the type of problem mentioned. The answer cannot be A as Kinesis service is for real time data streaming and specially the kinesis data analytics is used for below cases and the problem is unrelated to any of the below used case. Generate time-series analytics Feed real-time dashboards Create real-time metrics
Tralfalgarlaw
👍 1
The correct is D
Zelda28
👍 1
Selected: B
B aligns with the simpler approach and more dynamic as well which is suitable for longer run.
Zelda28
👍 1
Selected: D
Allows multiple consumers to process the messages independently.
M0SHE
👍 1
Selected: D
D is the right answer
AshokBabu
👍 1
My choice is D The only reason A is chosen because of incoming message rate, which is 100000. I was referring the document. If it is standard topic or standard queue, they support unlimited throughput. So, incoming message rate can't be the criteria for choosing option A
Syruis
👍 2
Selected: D
"(Amazon SOS)" should be "(Amazon SQS)" it blow my mind :/
BillyBlunts
👍 1
How are we to go into the test with such confusing answers....I agree as well that it should be D. However, I want to select the answer they say is right so I can pass the test. Everywhere I have looked including Quizlet who I think is pretty reliable, the answer is A. Would you guys say it is better to go with the answer they select, even though we majority agree it is a different answer?
sabs1981
👍 1
Selected: D
Decoupling ingestion from subscription of messages. Should be done via queues and ideally SQS should be used in this case.
Shanky9916
👍 2
The answer is D, because de-coupling is used only in SNS and SQS.
Ranfer
👍 1
Selected: D
Producer and consumer architecture works best with SQS (SNS) services
Kaab_B
👍 1
Selected: D
The solution that meets the requirements of decoupling the solution and increasing scalability, considering the varying number of messages and sudden increases, is option D: Publish the messages to an Amazon Simple Notification Service (SNS) topic with multiple Amazon Simple Queue Service (SQS) subscription
miki111
👍 1
Option D MET THE REQUIREMENT
RupeC
👍 2
Selected: D
SNS + SQS Fan-out architecture. This is where messages from an SNS topic are fanned out to multiple SQS queues that subscribe to a topic. Thus the consumers can take their feeds from different queues.
jaydesai8
👍 1
Selected: D
SQS have unlimited throughput and help easily decoupling the applications D makes more sense
gustvomonteiro
👍 2
D makes more sense! Keyword: Decoupling= SQS
Agustinr10
👍 1
Selected: D
If its says decouple, then is SQS
nbspencer
👍 1
Selected: D
Kinesis Data Analytics is for querying i think D is more likely the better answer
mbuck2023
👍 1
Selected: D
SNS+SQS fan out makes more sense here. Answer D.
Bmarodi
👍 1
Selected: D
Keyword: Decoupling= SQS
antropaws
👍 1
Selected: D
Confusing, but I'm going with my initial guess: It's D: For most standard queues (depending on queue traffic and message backlog), there can be a maximum of approximately 120,000 in flight messages (received from a queue by a consumer, but not yet deleted from the queue). If you reach this quota while using short polling, Amazon SQS returns the OverLimit error message. If you use long polling, Amazon SQS returns no error messages. To avoid reaching the quota, you should delete messages from the queue after they're processed.
omoakin
👍 1
Chat GPT says C is the correct answer here
sbnpj
👍 1
Selected: D
Option A suggests persisting the messages to Amazon Kinesis Data Analytics, which focuses on analytics and processing rather than decoupling and scalability. Option D is correct because- By publishing the incoming messages to an SNS topic, you can ensure that multiple consumer applications and microservices can subscribe to the topic to receive the messages independently. The decoupling allows the producer application to send messages without being tightly coupled to the consumers.
TuliSinger
👍 1
Selected: D
D is correct
redx1
👍 1
reponse: D
thanhvx1
👍 2
Selected: D
D By using the fanout pattern SNS + SQS, you can easily decouple your applications
Musti35
👍 1
Correct Answer :D Unlimited Throughput: Standard queues support a nearly unlimited number of transactions per second (TPS) per API action. only FIFO has limited 30000 message persecond but you can use standard sqs
channn
👍 6
Selected: D
Key words: decouple
acuaws
👍 1
so which on is truly the correct answer? I'm new to the site and not sure what's the difference between the circle answer and the most voted?
linux_admin
👍 1
Selected: D
Option D proposes publishing the messages to an Amazon SNS topic with multiple Amazon SQS subscriptions. This would decouple the ingestion and consumer applications, allowing for easy scaling of the consumer applications. Additionally, SNS can handle sudden spikes in incoming messages and automatically scale to handle increased traffic. The SQS subscriptions can also buffer messages and provide reliable delivery to consumer applications, allowing them to process messages at their own pace and scale independently.
alexiscloud
👍 1
D. SNS and SQS to create a decoupled and scalable architecture for ingesting and consuming incoming messages.
skr05
👍 1
Selected: D
this should be the answer
PaoloRoma
👍 5
Selected: A
A) decouples and scales - reference to Kinesis Data Analytics implies using Kinesis Data Streams to me B) scales but it is not clear how it decouples C) decouples, but does not scale: single shard and single lambda D) decouples, but does not scale: single shard and single lambda
khetran
👍 1
Selected: A
A because key point here is that there are multipe consumer which consume the data immidiately , and kenesis fan out is the option we can use to scale out
KittieHearts
👍 2
Selected: A
"messages varies drastically and sometimes increases suddenly to 100,000 each second" meaning it can increase even more than 100,000 A would make the most sense based on this.
bilel500
👍 2
Selected: D
Kinesis Streams differ from SNS in many ways: Lambda polls Kinesis for records up to 5 times a second, whereas SNS would push messages to Lambda. records are received in batches (up to your specified maximum), SNS invokes your function with one message.
TUANHA2312
👍 3
Selected: D
keypoint is: The company wants to decouple the solution and increase scalability.
awscerts023
👍 1
Selected: D
Fan Out pattern , can also filter messages to different consumers if needed.
remand
👍 1
Selected: C
C. Write the messages to Amazon Kinesis Data Streams with a single shard. Use an AWS Lambda function to preprocess messages and store them in Amazon DynamoDB. Configure the consumer applications to read from DynamoDB to process the messages. While using Amazon SNS and SQS can also decouple the solution and provide a level of scalability, using Kinesis Data Streams with Lambda and DynamoDB provides a more flexible and scalable solution for ingesting and processing large amounts of data in near real-time. With Kinesis, the ingestion application can write messages to a stream that can scale horizontally to handle increased traffic, while the Lambda function provides the ability to preprocess the messages before storing them in a scalable NoSQL database like DynamoDB. This setup also allows for better control and optimization of the processing pipeline.
Ello2023
👍 6
This answer is also valid, however do you think it would benefit to pay more by being with Kineses which is real time (Unnecessary) and writing an SQL custom code to process this when you can simply have SNS with SQS which process more data, sever-less, cheaper.
STRELOK
👍 1
Selected: D
Answer is D
Mourner
👍 3
Selected: D
Company needs to decouple and improve scalabilty.
m2khp
👍 2
Selected: D
Answer is D. A is an overkill.
Abdel42
👍 1
Selected: D
I think it is D because the limits mentioned are valid for FIFO queues
LuckyAro
👍 2
Anytime you see the word "decouple" expressly or Implied ...... think SQS that's it's primary purpose !
harsh_it
👍 2
That limit is for SQS FIFO queue not for standard queue.
SilentMilli
👍 3
Selected: C
By writing the incoming messages to Kinesis Data Streams and using a Lambda function to preprocess and store the messages in DynamoDB, the company can decouple the ingestion application from the consumer applications and increase scalability. Kinesis Data Streams can automatically scale to handle the sudden increases in the number of messages, and the Lambda function can be triggered to process the messages as they arrive. The consumer applications can then read and process the messages from DynamoDB.
SilentMilli
👍 3
After much thought, I think D is the right answer.
PuppetMaster2k
👍 1
Selected: D
The correct answer should be 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.
studystudy999
👍 1
Selected: D
D is the answer
career360guru
👍 9
Selected: A
A is correct SNS can not handle 100K per second message throughput. As per the documentation it can only handle upto 300 msgs/sec.
Zerotn3
👍 1
Vote D (100%)
Mindvision
👍 2
Answer is A. Considering messages can reach 100,000msg/sec. SQS does 3000-30,000msg/sec high throughput
HayLLlHuK
👍 1
that's why they mentioned 'multiple SQS subscriptions'
Teerx
👍 3
Who decided the correct answer is A ?? the admin ??
NikaCZ
👍 3
multiple subscribers at the same time = SNS. decoupling = SQS
yoben84
👍 2
It can't be D because the maximum throughput of SQS is 3000 msg/sec (with batching) so far lower than the 100 000 request/sec as specified. However, data analytics has a throughput of 100 mb/sec , so it can absorb such load
venice1234
👍 1
SQS Standard Queues support up to 120,000 in-flight messages. Indeed if they exceed 100,000 messages per second it will quickly overwhelm SQS and it will just ignore new requests.
Nandan747
👍 1
WTH, how is it A?? It talks about multiple subscribers consuming the data.
MaxMa
👍 1
Why C does not work?
naveedpk00
👍 1
Option C involves writing the messages to Amazon Kinesis Data Streams with a single shard and using an AWS Lambda function to preprocess the messages and store them in DynamoDB. This option would not be the most efficient solution, as it would require the consumer applications to continuously poll DynamoDB for new messages, which could impact their performance.
stepman
👍 1
How do we know that the current application being used for ingestion is compatible with any of the AWS services? I believe we don’t so I think the answer would be B. Maybe not a permanent solution, but the initial one.
stepman
👍 1
My bad.. D .. we can leave the ingestion app unchanged and decouple the messages from it to an SQS queue
Wajif
👍 1
Selected: D
Fanning out to multiple subscribers at the same time is SNS. SQS is decoupling.
langiac
👍 2
Selected: D
me toooo
gilang_from_indonesia
👍 4
It should be D. Key words: Persist, decouple
yuchip
👍 1
A, Amazon Kinesis makes it easy to collect, process, and analyze real-time, streaming data so you can get timely insights and react quickly to new information.
Wpcorgan
👍 1
D is correct
ABCMail
👍 1
Selected: D
SQS is a better solution for decoupling
renekton
👍 1
Selected: D
decoupling an application using sqs and fanout using sns
mikey2000
👍 3
Why is A the correct answer?
azmne
👍 1
Selected: A
D because decoupling = SQS in most cases,
bont
👍 2
D fan out to SQS
keezbadger
👍 1
D: By default, FIFO queues support up to 3,000 messages per second with batching or up to 300 messages per second (300 send, receive, or delete operations per second) without batching. So with batching it solved the question and option D also mentions “multiple”. So D is the right choice.
Six_Fingered_Jose
👍 3
Selected: D
I go for D because decoupling = SQS in most cases, and they did mention SNS into multiple SQS so with multiple SQS you can handle more than 100k requests
cark0728
👍 3
Selected: D
D가 정답이다
Drekorig
👍 1
D'accord
Six_Fingered_Jose
👍 3
yeah i agree
17Master
👍 1
Ans is D
iCcma
👍 1
Selected: A
A
iCcma
👍 4
friends certainly D makes a lot of sense, so even with the answer I gave, I'm curious, here I leave a link with a debate with very good arguments. I want to change my answer to D
PhilN135
👍 1
Selected: D
D - it is
queen101
👍 1
DDDDDDD
brushek
👍 1
Selected: A
Kinesis Data Analytics integrates with Amazon Kinesis Data Streams and Amazon Kinesis Data Firehose so you can readily ingest streaming data. Just point Kinesis Data Analytics at the input stream and it will automatically read the data, parse it, and make it available for processing. You can emit processed results to other AWS services including Amazon S3, Amazon Redshift, and Amazon OpenSearch Service through Kinesis Data Firehose. You can also send output data to Amazon Kinesis Data Streams to build advanced stream processing pipelines.
Gatt
👍 6
Selected: A
Why D? Won't the 100,000 messages per second requirements make SNS a poor choice? Since AWS states that SNS has a per region limit of API requests per second and the maximum is 30,000. But then, C is also wrong, since 1 shard can only support a maximum input of 1000. B is wrong since you're not decoupling and once it increases to 100,000 ASG won't keep up, as it take too long to adapt. A could be right? If you already have a stream in place, you can then feed it onto Kinesis Analytics and apply whatever procedures you were doing initially with your applications.
th3cookie
👍 1
You have one SNS fan out to multiple SQS. this means the 30000 limit is gone.
brushek
👍 2
I'm for A: Kinesis Data Analytics integrates with Amazon Kinesis Data Streams and Amazon Kinesis Data Firehose so you can readily ingest streaming data. Just point Kinesis Data Analytics at the input stream and it will automatically read the data, parse it, and make it available for processing. You can emit processed results to other AWS services including Amazon S3, Amazon Redshift, and Amazon OpenSearch Service through Kinesis Data Firehose. You can also send output data to Amazon Kinesis Data Streams to build advanced stream processing pipelines.
BoboChow
👍 3
Selected: D
This a senario of Fan Out Pattern
hanhdroid
👍 1
Selected: D
D also for me
airraid2010
👍 1
Selected: B
When it comes to decoupling an application, you should think about SQS.
airraid2010
👍 1
oops I picked the wrong answer. should have been D.
D2w
👍 4
Selected: D
Decouple is your keyword for SQS
Rock08
👍 1
Selected: D
NOT : Amazon Kinesis Data Analytics is the easiest way to transform and analyze streaming data in real time using Apache Flink.
rein_chau
👍 59
Selected: D
D makes more sense to me.
daizy
👍 23
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 uses Amazon SNS and SQS to publish and subscribe to messages respectively, which decouples the system and enables scalability by allowing multiple consumer applications to process the messages in parallel. Additionally, using Amazon SQS with multiple subscriptions can provide increased resiliency by allowing multiple copies of the same message to be processed in parallel.
SilentMilli
👍 23
By default, an SQS queue can handle a maximum of 3,000 messages per second. However, you can request higher throughput by contacting AWS Support. AWS can increase the message throughput for your queue beyond the default limits in increments of 300 messages per second, up to a maximum of 10,000 messages per second. It's important to note that the maximum number of messages per second that a queue can handle is not the same as the maximum number of requests per second that the SQS API can handle. The SQS API is designed to handle a high volume of requests per second, so it can be used to send messages to your queue at a rate that exceeds the maximum message throughput of the queue.
9014
👍 3
of course, the answer is D
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
Option D uses Amazon SNS fan-out to multiple Amazon SQS subscriptions, which cleanly decouples the ingestion application from dozens of consumer applications and microservices. Each consumer can process from its own SQS queue independently, so a slow or failed consumer does not block the others, and SQS buffers sudden spikes instead of forcing synchronous processing. Standard SQS queues and SNS topics are designed for high-throughput, distributed workloads, making this the right architecture for traffic that can jump to 100,000 messages per second. The design also supports retries, dead-letter queues, and independent scaling per consumer, which directly addresses the scalability requirement.Why the Other Options Are Wrong
Option A misuses Amazon Kinesis Data Analytics, which is an analytics service that reads from streaming sources rather than a general-purpose message distribution layer for dozens of applications. Option B scales EC2 instances based on CPU but does not decouple producers from consumers, and Auto Scaling reacts too slowly for sudden 100,000-messages-per-second bursts. Option C is limited by a single Kinesis shard, whose throughput is far below the stated burst, and having consumers poll DynamoDB adds latency and unnecessary read pressure. None of these alternatives provides the durable, per-consumer buffering and fan-out model that SNS with SQS subscriptions provides.Community Comment Notes
PhucVuu correctly warned not to confuse Kinesis Data Analytics with Kinesis Data Streams, noting that analytics services are for analysis rather than delivering messages to consumer applications. Channn focused on the key requirement with the short note “Key words: decouple,” which aligns with the SNS-to-SQS fan-out design. Buruguduystunstugudunstu pointed out that option C would make consumers continuously poll DynamoDB, which could impact performance, reinforcing why D is cleaner. Some learners raised SNS throughput concerns, but the standard SNS-to-SQS fan-out pattern is the intended scalable decoupling solution for this scenario.Official Reference
Exam Strategy
When a question says “decouple” and mentions many consumers or microservices, look for fan-out with one SQS queue per consumer. Throughput limits should steer you away from single-shard Kinesis and toward SNS with SQS subscriptions.
Frequently Asked Questions
Why is Kinesis Data Streams with a single shard wrong for 100,000 messages per second?
A single Kinesis shard supports roughly 1 MB/s or 1,000 records/s, so it cannot absorb a sudden 100K/sec burst. Option D scales through SNS fan-out to multiple SQS queues.
Does SNS fan-out to SQS still fit if dozens of microservices consume the same messages?
Yes. Each microservice gets its own SQS subscription and queue, so it consumes independently, buffers bursts, and can scale or retry without affecting other consumers.
Related Analysis
Practice All SAA-C03 Questions
Access 120 questions with complete answers and detailed explanations.
View Full SAA-C03 Practice Test →