zlacker

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)

>>cyberf+(OP)
I 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.

>>cyberf+(OP)
maybe once you've processed a message, you resend it to a different queue, just in case?

>>cyberf+(OP)
Possibly this: https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQS...

>>hexene+w8
We 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.

>>ilogik+J1
That'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)?!?

>>cyberf+He
Or send everything to SNS and have two SQS queues subscribed to the topic.