zlacker

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.

>>Jemacl+(OP)
We point to an s3 object for any large payloads

>>somede+P
and there's a library around that can do it for you, at least in java

>>Jemacl+(OP)
Hard 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)

>>Jemacl+(OP)
The 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.

>>Jemacl+(OP)
We 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.

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

>>somede+P
Wouldn't sending and later retrieving millions of S3 objects be expensive?

>>mateus+ad
Wouldn't sending and later retrieving millions of S3 objects be expensive?

>>mark24+r2
That's a good idea, but wouldn't sending and later retrieving millions of S3 objects be expensive?

>>manish+Ck
We'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.

>>Jemacl+sA
Yes, 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.

>>maniga+qG
Gotcha.

>>Jemacl+pA
Messaging in our system is not high volume so not in this case. Also as I said - these big messages are pretty rare.

>>Jemacl+(OP)
Why 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?

>>mateus+UZ
Gotcha. That makes sense.