0

From this question, I know that it is possible to subscribe SQS to two different SNS, I want to understand pros and cons of the same, under any scenario, can I miss any notification?

tv1902
  • 181
  • 1
  • 3
  • 14
  • Pros and cons depend on your use case. What would you like to achieve by doing this? What is your aim? – Marcin May 17 '20 at 07:19
  • @Marcin So, I have a usecase where I need to update the status of order in DB. There are multiple SNS for different different status, my code does not need to worry about the type of status. All it needs to do is to do some business validation and update DB. So, I want to have single SQS for the same. – tv1902 May 17 '20 at 07:24
  • Sounds reasonable use case for having one sqs. You will not miss any notifications. Your sqs will have messages from both sns topics. Order is also not important? like one sns msg must be processed before sns from other or something like that? – Marcin May 17 '20 at 07:30
  • @Marcin the order will not be an issue as currently only one provider is publishing in both of the SNS. So, it will never happen that for particular usecase, it will provide two different status at a time – tv1902 May 17 '20 at 10:06

2 Answers2

1

To be honest there's no pros and cons it just depends why your designs would require multiple notification streams to be processed by the same consumer for the queue.

In the SLA you can see their uptime expectations, but like all technology you must be always be aware that there is a risk of failure.

I'd say for a solution that needs to aggregate a number of the same types of message i.e. across application or regions into a single consumer deployment then this would work out easier and cheaper to deploy.

Chris Williams
  • 32,215
  • 4
  • 30
  • 68
1

If you are concerned about missing notifications from a SNS subscription, you can associate a dead-letter queue.

junkangli
  • 1,152
  • 7
  • 14