Like what can it do that Simple #Queue Service can't? I know it's push based and that has it's benefits, and obvs it has integrations with SMS/email that probably come in handy, but those seem like improvements you could just make to #SQS instead of having a whole separate system.
@rayk fan-out is a use case I hear a lot, but it feels like you could do that without SNS. Maybe I don't understand the important aspect of fanning out.
Like say I have a DynamoDB table stream handler, can't I just "fan out" to all the queues right there in the Lambda? API calls are "push" too.
@schizanon You can add a subscription to an SNS topic without changing any code, and you can grant permission to add subscriptions across accounts, so you can have code that publishes notifications that can later be routed to different consumers (SQS, Lambda, etc) without modifying the code that does the publishing.
@schizanon It’s for a different kind of use case. Decoupling control to allow for limited self-service, or to allow one part of your system to not have “knowledge” of other parts.
I also tend to think of SQS as just a way to distribute work across many workers, while SNS is a way to publish notifications of when things happened. I don’t always need to distribute those notifications across workers, so I can choose to subscribe a Lambda, or if I have high volume I can subscribe an SQS queue and use a poller running in ECS/Fargate. My publishing code doesn’t need to know what the consumer is doing.
Add comment