4 ms·
We love SQS, but one of the problems we're running into lately is the 256kb per message limitation. We do tens of millions of messages per day, with a small per
by Jemaclus 7y ago
We love SQS, but one of the problems we're running into lately is the 256kb per message limitation. We do tens of millions of messages per day, with a small percentage of those reaching the 256kb limit. We're approaching the point where most of our messages will hit that limit.
What are our options for keeping SQS but somehow sending large payloads? Only thing I can think of is throwing them into another datastore and using the SQS just as a pointer to, say, a key in a Redis instance.
(Kafka is probably off the table for this, but I could be convinced. I'd like to hear other solutions first, though.
- somedev55 7y agoWe point to an s3 object for any large payloads
- m4r 7y agoHard to suggest smth without details, but imo 256kb per message is a lot and enough. One thing I would consider is storing such "messages" payload on s3, and sending notification to sqs allowing you to fetch given file and process it (this however might be expensive if you happen to have such high traffic)
- mark242 7y agoThe Java SDK for SQS automatically drops >256k messages into an S3 bucket and stores a pointer to the message in SQS itself. You set the bucket and the client transparently handles retrieving a message from SQS/S3 when necessary. Based on the structure of the message (UUIDv4) you could probably roll your own implementation in any language.
- Jemaclus 7y agoThat's a good idea, but wouldn't sending and later retrieving millions of S3 objects be expensive?
- manigandham 7y agoYes, and slow, if you're actually doing it for millions. The comment was saying the library only does it for messages that are over the size limit though.
- Jemaclus 7y agoGotcha.
- mateuszf 7y agoWe have a library that puts the payload in s3 bucket under random key, the bucket has expiration policy of few days. Then we generate http link to the object and send an sqs message with this url in metadata. The reader library gets data from s3, it doesn't even have to remove it. It will disappear automatically later. We do it "by ourselves", not using the provided lib, because that way it works both for SQS and SNS. The provided lib only supports SQS. Also our messages aren't typically very big, so we do this only if the payload size demands it.
- manish_gill 7y agoI've successfully been using Kafka in production with a tiny percentage of packets ~1Mb. We utilize gzip compression with chunking on some of those messages (system is legacy, no fancy compressed message format in use). IIRC, only had to modify settings at the broker level and it works perfectly fine.
- Jemaclus 7y agoWe've discussed switching to Kafka. There are some pros/cons to doing that. With respect to my problem above, our messages _could _conceivably approach 1MB (or even surpass it), so we're really just delaying the inevitable. That said, we're a long, long way from hitting that limit, so it's definitely something we're looking at. We just recently started gzipping our payloads, which buys us even more time.
- TeeWEE 7y agoWhy are your messages large? Messages should just be signalling events, like follows: OrderCreated(order_id=23) UserLoggedIn(user_id=342) etc. I guess you are sending the whole user object over the event bus? Isnt that an anti-pattern?