3 ms·

Pretty good and simple explanation, thanks a lot! There are a couple of things I‘m left wondering: When the SNS is used to notify through Email, Push or SMS t

Pretty good and simple explanation, thanks a lot! There are a couple of things I‘m left wondering: When the SNS is used to notify through Email, Push or SMS then even in the fan-out pattern, no SQS is involved on these paths, right? (seems to me that only on A2A paths SQS would be involved, at least from the diagrams) So is there anything else to help with reliability there that the notifications actually do go out? For workloads where you e.g. want to alert users through different means, not every user might have the same options selected, e.g. some only Push and others SMS and EMail; would that be modeled through different topics which have different combinations of subscribers attached (some only 1) or would it be better to skip SNS and push multiple messages to different queues directly?

jon-wood 4y ago
An SNS message is delivered to a number of endpoints, which can include email, push notifications, SMS, or various AWS services. In its payload the content to send to each type of endpoint so you can make sure it’s going through in the right format.
jack335 4y ago
Hi author here :) Thanks for your kind words. Regarding fanout. Yes exactly. Fanout doesn't mean it needs to involve SQS just it can involve SQS. It is also called a fanout pattern if you do a A2P and only notify Emails, SMS, etc. To your second question how the architecture would look like for different preferences of architecture. I think the main benefit of that architecture is that customer can subscribe to a topic. That means if your user A subscribes to the topic for Email and not in-app notification that is fine. It would be also just the one topic. The consumer/subscriber has the power to subscribe and unsubscribe to topics (similar like you can to newsletters basically). That is one of the main benefits. With a queue the producer would need to define which consumer will get the message and most probably it will be another application. Does that help? :)
zmgsabst 4y ago
I think it may depend on your architecture, but naively: - SQS to send alert, all modes - Lambda reading that queue, filtering on user settings - SNS per mode of communication, eg email or text My thinking is that you’d want to filter on user preference early, to prevent repeated work. A benefit of this approach is you prevent combinatorial complexity if you have both selection on kinds of alerts delivered and way to deliver alerts: the Lambda can handle all of that based on the user settings. And still a single SNS per communication channel. Your gating Lambda can also implement other features, like volume aware decisions — where it eg, rejects “marketing” messages if there have been too many to a single customer recently while still allowing through “transaction” messages.

jon-wood 4y ago

An SNS message is delivered to a number of endpoints, which can include email, push notifications, SMS, or various AWS services. In its payload the content to send to each type of endpoint so you can make sure it’s going through in the right format.

jack335 4y ago

Hi author here :) Thanks for your kind words. Regarding fanout. Yes exactly. Fanout doesn't mean it needs to involve SQS just it can involve SQS. It is also called a fanout pattern if you do a A2P and only notify Emails, SMS, etc. To your second question how the architecture would look like for different preferences of architecture. I think the main benefit of that architecture is that customer can subscribe to a topic. That means if your user A subscribes to the topic for Email and not in-app notification that is fine. It would be also just the one topic. The consumer/subscriber has the power to subscribe and unsubscribe to topics (similar like you can to newsletters basically). That is one of the main benefits. With a queue the producer would need to define which consumer will get the message and most probably it will be another application. Does that help? :)

zmgsabst 4y ago

I think it may depend on your architecture, but naively: - SQS to send alert, all modes - Lambda reading that queue, filtering on user settings - SNS per mode of communication, eg email or text My thinking is that you’d want to filter on user preference early, to prevent repeated work. A benefit of this approach is you prevent combinatorial complexity if you have both selection on kinds of alerts delivered and way to deliver alerts: the Lambda can handle all of that based on the user settings. And still a single SNS per communication channel. Your gating Lambda can also implement other features, like volume aware decisions — where it eg, rejects “marketing” messages if there have been too many to a single customer recently while still allowing through “transaction” messages.