Editing my conversation with @lajacobsson for @RealWorldSls and there's a nugget of insight that I wanted to share with you about implicit coupling that we often overlook when using SNS with SQS.
#serverless #aws
1/
#serverless #aws
1/
The topic is usually owned by the publisher and deployed in the publisher's stack, and the subscriber would reference its ARN via a CloudFormation stack output or something, creating an implicit coupling there.
2/
2/
You need message attributes to do filtering, but the publisher has no idea what the subscriber cares about (nor should it, loose coupling and all). So teams that own the subscriber have to ask the publisher's team to add the message attributes they need.
3/
3/
This creates inter-team dependency and coupling. The subscribers no longer have the autonomy to do their thing, project momentum is lost as teams have to rely on other teams to review, merge and deploy their changes.
I've seen too many projects die due to this type of dep.
4/
I've seen too many projects die due to this type of dep.
4/
AND, you're limited to 10 attributes per message, so for populate messages (like "order_created" in an e-commence app), it's also possible to actually run out of space!
5/
5/
It's something that I hadn't thought about, even though I've had plenty of other reasons to prefer EventBridge over SNS these days: lumigo.io/blog/5-reasons…
6/
6/
There's so much other good stuff in this conversation, can't wait to share with you all in a few weeks. Until then, check out the other conversations we have published already🤘
realworldserverless.com
end/
realworldserverless.com
end/
• • •
Missing some Tweet in this thread? You can try to
force a refresh
