Amazon SQS
SQS (Simple Queue Service) is a fully managed message queue that decouples producers from consumers — each message is delivered to and processed by exactly one consumer, then deleted. Standard queues offer unlimited throughput with at-least-once, best-effort-ordered delivery; FIFO queues guarantee strict ordering and exactly-once processing at lower throughput, making SQS the standard buffer for absorbing traffic spikes before they hit a database.
Swiggy buffers order-placement events in SQS during dinner-hour surges — 50,000 writes/second land in the queue while workers drain it into the database at a controlled, safe rate, so no order is lost even if the database briefly can't keep pace.
Visibility Timeout
When a consumer reads a message, it becomes invisible to other consumers for the visibility timeout window. Set this too short and the same message gets processed twice; too long and a crashed consumer delays retry for hours. For Lambda consumers, set it to at least 6x the function timeout.
Dead Letter Queue
After a message fails processing a configured number of times, SQS automatically routes it to a DLQ for inspection instead of retrying forever.
RememberSQS delivers each message to exactly one consumer. If multiple services need the same event, pair SQS with SNS fan-out — one queue per service.
Frequently Asked Questions
When should you use SQS Standard versus FIFO queues?
Standard queues prioritize throughput — nearly unlimited messages per second, at-least-once delivery, and best-effort ordering, meaning messages can occasionally arrive out of order or duplicated. FIFO queues guarantee strict ordering and exactly-once processing but cap throughput (300 msg/sec without batching, 3000 with). Use Standard for most workloads like image processing or notifications; use FIFO when order matters, like sequential financial transactions.
What's a common mistake engineers make with SQS?
Forgetting that a message isn't deleted automatically when a consumer reads it — it becomes invisible for the visibility timeout period, and if the consumer doesn't explicitly delete it after successful processing, it reappears in the queue and gets reprocessed. This can cause duplicate side effects if consumers aren't idempotent. Always design consumers to handle at-least-once delivery gracefully, and set visibility timeout longer than your typical processing time.