Explain Message Lifecycle & Visibility Timeout in Messaging

2 / 8

Amazon SQS

Message Lifecycle & Visibility Timeout

Understand how a message is hidden during processing and returned if the consumer fails.

SQS does not push messages or hold per-consumer acks like RabbitMQ. Instead, a consumer polls and receives a message, which the queue then hides from other consumers for the visibility timeout. The consumer processes the message and, on success, explicitly deletes it. If it does not delete within the timeout (because it crashed or was slow), the message becomes visible again and another consumer picks it up — this is how SQS achieves at-least-once delivery.

A library reservation shelf: when you take a book to read (receive), it is marked "on hold" so no one else takes it (visibility timeout). If you check it out (delete) it is yours; if you wander off and the hold expires, it goes back on the shelf for the next person.

Key Concepts

Choosing the visibility timeout is critical: too short and a slow-but-healthy consumer's message reappears and gets processed twice; too long and a genuinely failed message takes ages to retry. A consumer that needs more time can extend the timeout dynamically with ChangeMessageVisibility (a heartbeat).

Because failed messages reappear, SQS consumers must be idempotent, and repeatedly failing messages should be routed to a dead-letter queue.

What the interviewer is probing.

What the interviewer is probing.

1. "What is the visibility timeout?" *Probing:* the core concept. *Stalls:* "A delay." *Moves up:* the window after a receive during which the message is hidden from other consumers — it is not deleted until you delete it.

1. "What is the visibility timeout?"

2. "What happens if processing outlasts it?" *Probing:* the classic failure. *Stalls:* "Nothing." *Moves up:* another consumer receives the same message and it is processed twice.

2. "What happens if processing outlasts it?"

3. "How do you handle variable processing time?" *Probing:* the technique. *Stalls:* "A long timeout." *Moves up:* extend it with ChangeMessageVisibility as work progresses, rather than setting a long default that delays retries of genuine failures.

3. "How do you handle variable processing time?"

4. "Why must the consumer delete explicitly?" *Probing:* the model. *Stalls:* "It should not." *Moves up:* so a crash leaves the message to reappear — deletion is the acknowledgement.

4. "Why must the consumer delete explicitly?"