Reputation: 6180
We plan to use SQS standard queue for messaging. The messages are a bunch of records that need to be received in order at the consumer end. There are a few reasons due to which we plan not to use FIFO queues.
Given this we are evaluating the SQS extended library support to use S3 for storing message payloads. We would club all the linked records into one message and post it to SQS as one request. I have a few questions
Upvotes: 0
Views: 1490
Reputation: 7669
S3 introduces additional latency (at each end of the queue), depending on the payload size, whether the message publishers/consumers are in AWS or hosted elsewhere, and how much bandwidth an individual server instance has available to it. (Off the cuff, I’d guess it’s >200 ms for a 1 MB payload.) The cost will be pretty insignificant, especially if you set up appropriate bucket lifecycle policies to archive or delete old data. Don’t forget that S3 is strongly consistent on the initial create, but only eventually consistent for any updates to an object. If possible, don’t update an object once you have created it.
I don’t have any real world examples, but I’ll let you know if I find one.
You will probably find it simpler to implement what you need using some sort of database, as was suggested in the article that you linked (which explained the limitations of FIFO queues). Make sure your decision isn’t biased by looking for premature optimizations.
Upvotes: 1