In Amazon SQS, what does the visibility timeout do after a consumer calls ReceiveMessage, and why must the consumer still call DeleteMessage?

## The queue never pushes, and it never assumes success Amazon SQS does not deliver messages to consumers; consumers ask for them. The whole consumption model is three calls — `ReceiveMessage`, then your work, then `DeleteMessage` — and the visibility timeout is the safety mechanism that holds the middle step together. When you call `ReceiveMessage`, SQS does **not** remove the message. It returns a copy of the body along with a **receipt handle** — an opaque token identifying *this particular receive* of *this particular message* — and starts a clock. Until that clock expires, the message is *invisible*: no other `ReceiveMessage` call against the queue, from any consumer, will return it. That window is the **visibility timeout**. ## A lease, not a lock The distinction matters because it explains every behaviour that follows. A lock is held until released; a lease expires on its own. SQS deliberately chose a lease, because the queue has no way to know whether a silent consumer is busy or dead. If the consumer never comes back, the safe assumption is that the work did not happen, so the message becomes visible again and is handed to whoever asks next. That is why SQS gives you *at-least-once* delivery on standard queues: a message may be processed more than once whenever a lease expires before the delete lands. The queue is trading duplicate work for never silently losing work. ## The delete is the acknowledgement Nothing about a successful `ReceiveMessage` implies success of processing, so nothing about it deletes the message. Only `DeleteMessage` does — and it takes the *receipt handle*, not the message ID: ```python import boto3 sqs = boto3.client("sqs") resp = sqs.receive_message(QueueUrl=QUEUE_URL, MaxNumberOfMessages=1) for msg in resp.get("Messages", []): handle_work(msg["Body"]) # only after this succeeds sqs.delete_message(QueueUrl=QUEUE_URL, ReceiptHandle=msg["ReceiptHandle"]) ``` A message ID is stable for the life of the message; a receipt handle is issued fresh on every receive. If a message is received twice, you get two different handles, and you should always delete with the most recently received one — an older handle is not guaranteed to delete the message. Ordering matters too: deleting *before* the work finishes converts the queue to at-most-once and loses messages on a crash. Delete after. ## Defaults, ranges and overrides The queue attribute `VisibilityTimeout` sets the default for every receive, is 30 seconds on a new queue, and can be set from 0 seconds to 12 hours. `ReceiveMessage` also accepts a per-call `VisibilityTimeout` that overrides the queue default for just those messages, which is useful when one consumer handles a much slower class of work than the others. And `ChangeMessageVisibility` re-sets the timeout for an in-flight message from *now*, so a long job can renew its lease periodically; passing `0` does the opposite and releases the message immediately, which is the standard way to hand back work you have decided not to do. ## Watching it in production Two CloudWatch metrics tell the story: `ApproximateNumberOfMessagesVisible` is the backlog waiting to be received, and `ApproximateNumberOfMessagesNotVisible` is the count currently leased — messages received but neither deleted nor expired. A steadily climbing not-visible count with a flat visible count usually means consumers are receiving work and failing to delete it, which is a bug, not a backlog. ## The failure modes this design creates - **Timeout shorter than the handler.** The lease expires mid-flight and a second consumer starts the same work while the first is still running. This is the single most common SQS bug. - **Delete never called.** Every message is redelivered forever until it ages out or is routed away by the queue's redrive configuration. - **Deleting first, processing second.** A crash now loses the message permanently. - **Assuming a huge timeout is free.** A 12-hour lease means a crashed consumer's messages sit untouched for 12 hours before anyone retries them. The mental model to carry into an interview: SQS hands out a temporary, revocable lease and waits for an explicit acknowledgement. Everything else — heartbeating, batching, redelivery — follows from that one sentence.