Amazon SQS

What is Amazon SQS?

Amazon SQS (Simple Queue Service) is AWS’s fully-managed message queue — a durable buffer that lets services communicate asynchronously without being directly connected. A producer sends messages to a queue; consumers poll and process them; SQS handles the storage, delivery, scaling, and durability with no servers for you to manage. It’s one of AWS’s oldest and most reliable services, and the default first reach for decoupling components, absorbing load spikes (the queue buffers work when consumers can’t keep up), and smoothing asynchronous processing — the backbone of countless event-driven AWS architectures.

The two queue types, and how SQS behaves

SQS offers Standard and FIFO queues, and the difference matters. Standard queues give nearly unlimited throughput and at-least-once delivery with best-effort ordering — meaning messages can occasionally be delivered more than once and may arrive out of order. FIFO queues guarantee exactly-once processing and strict ordering, at lower throughput. The practical implication of Standard’s at-least-once delivery is the one teams forget: consumers must be idempotent, because the same message can be delivered twice, and non-idempotent processing (double-charging, double-creating) will break. Key mechanics: a consumer that receives a message gets a visibility timeout during which the message is hidden from others while it’s processed, and the consumer must delete it on success (if it doesn’t — e.g., it crashed — the message reappears for retry). Messages that repeatedly fail should route to a dead-letter queue for inspection rather than being retried forever.

SQS vs SNS vs Kafka — picking the right tool

SQS is a queue (point-to-point: a message is processed by one consumer), which contrasts with its common partner SNS (pub/sub: a message is fanned out to many subscribers) — the two are frequently combined in the “fan-out” pattern (SNS topic → multiple SQS queues) so several independent consumers each get their own copy of an event. And SQS differs from Kafka: SQS is a simple managed queue (messages consumed and deleted, no replay), while Kafka is a durable, replayable event log. The guidance: use SQS for straightforward async task/work queues and decoupling in AWS (simple, cheap, serverless); use SNS+SQS when one event must reach multiple consumers; use Kafka/Kinesis when you need high-throughput replayable streaming. The recurring mistakes are non-idempotent Standard-queue consumers, mishandling the visibility timeout (too short → duplicate processing of in-flight work; too long → slow retries), and not configuring a dead-letter queue so poison messages loop forever.

What people get wrong

• Non-idempotent consumers on Standard queues — at-least-once delivery means duplicates happen; processing must tolerate the same message twice or use FIFO.
• Misusing the visibility timeout: too short causes another consumer to grab a message still being processed; too long delays retries after a crash — size it to real processing time.
• No dead-letter queue — without one, messages that always fail get retried endlessly; a DLQ isolates poison messages for inspection.

Primary source: Amazon SQS documentation