Amazon SQS, step by step.

1. What is Amazon SQS?

Amazon Simple Queue Service, or SQS, is a fully managed message queue from AWS. It lets one service send a message to a queue while another service receives and processes it later.

A queue acts as a buffer between services. The producer does not need to wait for the consumer to be ready, and AWS manages the queue servers for you.

2. How a message moves

A producer sends a message to an SQS queue. A consumer asks SQS for messages using a receive request. SQS returns the message and a receipt handle.

The consumer performs its work. If the work succeeds, it deletes the message using the receipt handle. Deleting is the acknowledgement that tells SQS the work is complete.

SendMessage → ReceiveMessage → process → DeleteMessage

If the consumer crashes before deleting the message, SQS can make it available again. This protects the message, but the consumer should be safe to run the same message more than once.

3. Visibility timeout

After SQS gives a message to a consumer, the message remains in the queue but becomes temporarily invisible to other consumers. This period is the visibility timeout.

The consumer should finish its work and delete the message before the timeout expires. If it does not, the message becomes visible again and another receive request can return it.

The default visibility timeout is 30 seconds, and it can be adjusted for a queue or extended for a message that needs more time. A timeout prevents simultaneous processing in the normal case, but SQS uses at-least-once delivery, so duplicate delivery is still possible.

4. Standard and FIFO queues

Standard queue

A Standard queue is designed for very high throughput. Messages can occasionally be delivered more than once, and their order is not guaranteed. Use an idempotent consumer when processing must not apply the same business action twice.

FIFO queue

A FIFO queue preserves order within a MessageGroupId and supports deduplication. Messages in the same group are processed in sequence. Use FIFO when order is part of the business rule, such as changing the state of one account or one order.

5. Retries and dead-letter queues

When a consumer fails, the message can become visible again and be retried. A dead-letter queue, or DLQ, is a separate queue where SQS can move a message after it has failed a configured number of times.

A DLQ keeps a repeatedly failing message from blocking normal work. The team can inspect the message, fix the cause, and decide whether to retry or discard it.

6. A practical example

Imagine an online store:

Order Service → order-payment-queue → Payment Worker

The Order Service sends a payment request and immediately returns to its own work. A Payment Worker receives the request, charges the customer, and deletes the message only after the payment result is safely recorded. Several Payment Workers can read from the same queue and share the work.

SQS is a good fit when each message represents a task for one available worker. Kafka is a better fit when many independent applications need to read and replay a durable event stream.