SQS has “simple” in the name, but after working with it for a while, I’ve learned it’s only simple on the surface. In this video I break down the gotchas that can quietly turn into big system design problems later—especially when you start caring about high availability, disaster recovery, and multi-region architectures. The first big limitation: SQS queues are region-specific. Once you create a queue in a region, that’s where it lives, and that can be painful if your architecture spans multiple regions. To work around that, I talk about using SNS (which is global) as a publisher so you can broadcast messages into SQS queues across different regions. That helps with flexibility and resilience, but it adds complexity and it doesn’t magically solve the hardest part: deduplication. Because SQS is at-least-once delivery, duplicates are always on the table—especially if two regions can process the same message. I walk through practical approaches like using an external multi-region datastore for dedupe (with race-condition considerations), or designing idempotent/self-replicating processing logic. I also cover why configuration matters: visibility timeout (to avoid reprocessing while a message is still being handled) and message retention period (so your consumers keep up before messages expire).