3 ms·
We've used SQS with great results (and reliability) for many years now, but I am interested to hear the author talking about 'replaying queues' to replicate fau
by cyberferret 7y ago
We've used SQS with great results (and reliability) for many years now, but I am interested to hear the author talking about 'replaying queues' to replicate faults. I never realised you could do this with SQS. Or can you? I thought once a queue item was processed and deleted, that was it, it was gone forever, but perhaps you can see historical queue data somewhere? (without having to store it yourself)
- ilogik 7y agomaybe once you've processed a message, you resend it to a different queue, just in case?
- cyberferret 7y agoThat's actually a neat idea. Since we don't have to pay for number of items in a queue, I am thinking we could create a dummy queue and just handball all incoming messages to it for safekeeping (at least for 14 days)?!?
- kondro 7y agoOr send everything to SNS and have two SQS queues subscribed to the topic.
- hexene 7y agoPossibly this: https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQS...
- cyberferret 7y agoWe actually already use the DeadLetterQueues in our service at the moment, but these are when failed SQS deliveries happen, then they get replicated to the DLQ. I am more interested in diagnosing successful SQS deliveries after the fact, to see what the payloads were in case there was a downstream problem. It seems that SQS deliveries that don't get a 200 response from our service go to the DLQ, but those that get a successful 200 disappear into the ether.
- tybit 7y agoI think he’s saying that you can publish to a queue without any subscribers, and only play the messages for some recovery operation. It is limited as there’s a maximum life time of 14 days for SQS messages among other limits.