@schizanon meaning - the architecture is deliberately pretty simple on the event provider side, which keeps it low cost and minimal. There are use cases for fire and forget events. Anything more complex needs a queue or stream.
@ak I still think they should just merge the two tools; make SQS do push, or make SNS do retries. I don't even care if they still use each other internally, just don't expose it to end-users!
@schizanon In practice, there's little difference if you consume SQS via Lambdas since they pull automatically really fast. If you are doing your own consumers you probably want something like a pub/sub with some delivery guarantee (mqtt or something - aws has a hosted version called iot core)
@schizanon
They have different design goals that are opposed to each other. SNS is low-latency but low-reliability. SQS is highly reliable but with higher latency.
Ensuring message delivery adds overhead (you need to store the message to disk, then a consumer needs to fetch it, then the consumer needs to acknowledge receipt, then the message is removed). And since SQS persists messages it also has a dead-letter queue for re-processing messages that aren't handled successfully.
SQS can also ensure a FIFO where SNS cannot. So each message needs an ID to ensure they're delivered in order.
It mostly depends on what your use-case is. Do you want to send thousands of push-notifications and you don't care about a few failing? SNS would be fine. Do you want to share data between applications? Probably SQS.
Add comment