Что произойдёт, если Lambda, обрабатывающая SQS message, упадёт?

Механизм обработки ошибок в связке Lambda + SQS

Когда Lambda читает сообщения из SQS через event source mapping, она сама управляет удалением: только при успешном завершении функции сообщения удаляются из очереди. Если функция выбрасывает исключение или завершается с ошибкой, Lambda не вызывает DeleteMessage — сообщения возвращаются в очередь после истечения visibility timeout.

Жизненный цикл сообщения при сбое

1. Lambda poller получает batch (до 10 000 сообщений для стандартной очереди, до 10 для FIFO).
2. Функция падает — batch целиком остаётся в очереди.
3. По истечении VisibilityTimeout сообщения снова становятся видимыми и попадают в следующий вызов.
4. Счётчик ApproximateReceiveCount увеличивается при каждом получении.
5. Когда счётчик достигает maxReceiveCount из redrive policy, сообщение перемещается в Dead Letter Queue (DLQ).

Runnable пример: Lambda с partial batch response

import json
import boto3

def handler(event, context):
    """
    Partial batch response — возвращаем только те сообщения,
    которые не удалось обработать. Успешные Lambda удалит сама.
    Требует: FunctionResponseTypes = ["ReportBatchItemFailures"]
    """
    failures = []

    for record in event["Records"]:
        message_id = record["messageId"]
        try:
            body = json.loads(record["body"])
            process_order(body)          # ваша бизнес-логика
        except Exception as exc:
            print(f"Failed to process {message_id}: {exc}")
            failures.append({"itemIdentifier": message_id})

    # Возвращаем только упавшие — они вернутся в очередь
    return {"batchItemFailures": failures}


def process_order(body: dict) -> None:
    """Idempotent обработка: проверяем, не выполнен ли заказ уже."""
    order_id = body["orderId"]
    db = boto3.client("dynamodb")

    # Idempotency check — предотвращает двойную обработку при retries
    response = db.get_item(
        TableName="orders",
        Key={"orderId": {"S": order_id}}
    )
    if response.get("Item", {}).get("status", {}).get("S") == "processed":
        return  # уже обработан, пропускаем

    # ... основная логика ...
    db.put_item(
        TableName="orders",
        Item={"orderId": {"S": order_id}, "status": {"S": "processed"}}
    )

Конфигурация через AWS CLI

# Создать DLQ
aws sqs create-queue --queue-name orders-dlq

# Настроить redrive policy на основной очереди
aws sqs set-queue-attributes \
  --queue-url https://sqs.us-east-1.amazonaws.com/123456789/orders \
  --attributes '{
    "RedrivePolicy": "{\"deadLetterTargetArn\":\"arn:aws:sqs:us-east-1:123456789:orders-dlq\",\"maxReceiveCount\":\"3\"}",
    "VisibilityTimeout": "300"
  }'

# Включить partial batch response на event source mapping
aws lambda update-event-source-mapping \
  --uuid <mapping-uuid> \
  --function-response-types ReportBatchItemFailures

Подводные камни

• VisibilityTimeout меньше времени выполнения Lambda. Сообщение станет видимым до завершения функции, и другой worker начнёт его параллельную обработку. Устанавливайте timeout очереди не менее чем в 6 раз больше timeout функции.
• Большой batch без partial batch response. Один «ядовитый» message роняет всю партию — Lambda повторяет весь batch, включая уже успешно обработанные сообщения. Всегда включайте ReportBatchItemFailures.
• Отсутствие idempotency. SQS гарантирует доставку at-least-once, не exactly-once. При retry бизнес-операция (например, списание денег) может выполниться дважды. Используйте idempotency key в БД или Idempotency Powertools for Lambda.
• Нет DLQ. Poison message с постоянной ошибкой будет вечно крутиться в очереди, потребляя invocations и capacity. Без DLQ невозможно его изолировать и проанализировать.
• FIFO-очередь блокирует MessageGroup. При ошибке в FIFO-очереди все последующие сообщения той же MessageGroupId застревают до разрешения проблемы — partial batch response здесь не помогает.
• Lambda concurrency throttle. Если Lambda достигает лимита concurrency, SQS messages накапливаются, ReceiveCount растёт — сообщения уходят в DLQ не из-за ошибки логики, а из-за throttle. Следите за метрикой Throttles.
• Игнорирование метрики ApproximateAgeOfOldestMessage. Растущий возраст старейшего сообщения — первый сигнал, что очередь не дренируется. Без алертов на эту метрику проблему можно заметить слишком поздно.
• DLQ без обработчика. Мёртвая очередь — не корзина для мусора. Без алерта на её глубину и отдельной Lambda-обработчика бизнес-события молча теряются.

• Считать, что сообщение удаляется при старте обработки.
• Не настраивать DLQ/redrive policy.
• Не делать handler idempotent.

• Описывает visibility timeout и retry.
• Учитывает batch/partial batch behavior.
• Понимает DLQ и idempotency.