SysPad › Lessons › messaging lessons › SQS

How SQS works

Fully managed message queue. Standard queues offer near-unlimited throughput. FIFO queues guarantee exactly-once processing and strict ordering at up to 70k TPS (high-throughput mode).

SQS is the shock absorber of a distributed system. Instead of one service calling another and hoping it’s awake, the caller drops a message in a queue and walks away. That one move decouples producers from consumers, so a traffic spike becomes a longer line, not a pile of dropped requests.

What you will learn

How does a queue let a fast producer and a slow consumer coexist without dropping work?
What’s a "visibility timeout", and why does it mean a message is delivered at least once?
Standard vs FIFO: what do you give up for strict ordering?
Where do messages go when a consumer keeps failing to process them?

Decoupling: a buffer between services

A queue holds messages from producers until consumers pull them off. The producer doesn’t wait for processing, and the consumer doesn’t have to keep up in real time, the queue absorbs the difference.

Each message is processed by one consumer (point-to-point). If you need many services to each get a copy, that’s a job for SNS or EventBridge, not a queue.

Visibility timeout and at-least-once delivery

When a consumer receives a message, SQS doesn’t delete it, it hides it for a visibility timeout. The consumer must explicitly delete the message after processing. If it crashes first, the timeout lapses and the message reappears for another attempt.

Why might the SAME message be processed twice?

If processing takes longer than the visibility timeout, the message becomes visible again and a second consumer grabs it, while the first is still working. Both may finish. Set the timeout above your worst-case processing time, and make the work idempotent so a repeat is harmless.

Standard vs FIFO

Standard queues give nearly unlimited throughput, but only best-effort ordering and at-least-once delivery (duplicates possible). FIFO queues guarantee strict ordering and exactly-once processing, de-duplicating repeated sends within a 5-minute window, at lower throughput (though a high-throughput FIFO mode reaches tens of thousands of messages/sec).

⚓ Standard powers most background-work queues; FIFO suits ordered command/event streams per entity.

Dead-letter queues: where poison messages go

Some messages can never be processed (malformed data, a bug). Without a safety net they’d be retried forever, blocking the queue. A dead-letter queue (DLQ) catches them: once a message has been received maxReceiveCount times without being deleted, SQS moves it to the DLQ.

There you can inspect, alarm on, and replay them, without poisoning the main queue.

Flashcards

A burst of orders arrives but workers are at capacity. With SQS in front, what happens?: The burst queues up and workers drain it at their own pace. Producer and consumer scale independently; nothing is dropped.
A consumer crashes after receiving a message but before deleting it. Then what?: The visibility timeout lapses, the message reappears, and another consumer retries it. That’s why SQS is at-least-once.
Why must SQS consumers be idempotent?: Standard SQS is at-least-once: the same message can arrive more than once, so processing it twice must not cause harm.
You need messages processed in strict order with no duplicates. Standard or FIFO?: FIFO, it guarantees ordering and exactly-once processing, at the cost of much lower throughput than Standard.
A malformed message keeps failing and blocking your queue. What catches it?: A dead-letter queue. After maxReceiveCount failed receives, SQS moves the message there for inspection/replay.

Sources

Open the SysPad canvas · Official SQS documentation