Полученное сообщение SQS не удаляется, а становится невидимым на время visibility timeout. Если потребитель не удалил его за это время, оно снова видно и уйдёт другому — повтор.
А ещё Отсюда at-least-once и обязательная идемпотентность
Так подсказку видит пользователь sotto на живом собеседовании — за пару секунд, пока вы думаете вслух.
Модель SQS: ReceiveMessage возвращает сообщение и делает его невидимым для других получателей на visibility timeout (по умолчанию 30 с, до 12 часов). Потребитель обрабатывает и вызывает DeleteMessage с receipt handle. Если не удалил — по истечении таймаута сообщение снова появляется в очереди и получит его кто-то другой (или тот же).
Почему так: брокер не знает, жив ли получатель; таймаут — способ автоматически повторить работу упавшего воркера.
Подводные камни:
sottoChangeMessageVisibility в процессе;maxReceiveCount: после N получений без удаления сообщение переносится в очередь недоставленных.Standard-очередь вообще не гарантирует единственную доставку — дубли возможны и без таймаутов, поэтому обработка должна быть идемпотентной.
Один верный вариант. Подумайте, потом откройте ответ.
Модель exchange/binding/queue, ack/nack и publisher confirms, prefetch, DLQ через DLX, отложенные сообщения, SQS Standard vs FIFO и visibility timeout.
sotto слышит вопрос интервьюера и показывает короткий ответ и план, как в блоке «Коротко». Оставьте контакт — пришлём доступ и промокод.