Реализация Serverless Event-Driven архитектуры на AWS

Проекты, где Lambda дёргает Lambda напрямую через SDK — это связанность, хрупкость и сложность отладки. Когда появляется пятнадцатый потребитель того же события, приходится обновлять каждый источник. Event-Driven архитектура на серверлес решает это: компоненты общаются через события, а не прямые вызовы. Lambda функция не знает, кто ещё подписан на результат её работы. Это обеспечивает слабую связность, независимый масштаб и возможность добавлять новых потребителей без изменения источника. Наш опыт в десятках проектов подтверждает: такой подход в 3-5 раз ускоряет внедрение новых сервисов по сравнению с монолитным связыванием, а стоимость инфраструктуры снижается на 30-50% за счёт отказа от неиспользуемых ресурсов.

Почему Event-Driven, а не прямое связывание?

Прямые вызовы Lambda из Lambda (через SDK Invoke) создают жёсткие зависимости. Если процесс оплаты дёргает сервис доставки, а через месяц нужен фрод-фильтр, приходится править код оплаты. В event-driven модели каждый сервис публикует события, а новые потребители подписываются без изменений источника. Это радикально упрощает эволюцию системы и позволяет независимо деплоить компоненты.

По данным AWS, EventBridge обрабатывает свыше 4 трлн событий в месяц, обеспечивая задержку менее 100 мс.

Сравните: при прямых вызовах отказ одного звена рушит всю цепочку. EventBridge с SQS даёт гарантию доставки и автоматические ретраи — в 10 раз надёжнее, чем ручная обработка ошибок.

Архитектура на примере e-commerce

Обработка заказа без event-driven: PlaceOrder → ValidateInventory → ProcessPayment → SendEmail → UpdateAnalytics — всё последовательно, тесно связано.

С event-driven:

[Client] → PlaceOrder Lambda
↓ EventBridge: order.created
/ | \
ValidateInv SendEmail Analytics
↓ EventBridge: inventory.reserved
↓ ProcessPayment
↓ EventBridge: payment.processed
/ \
FulfillOrder SendReceipt

Каждый сервис реагирует на события независимо. Новый сервис (например, fraud detection) подписывается на order.created без изменений существующего кода.

Как это работает на практике

AWS EventBridge: реализация

# Custom event bus + rule + target
resource "aws_cloudwatch_event_bus" "orders" {
  name = "orders-bus"
}

resource "aws_cloudwatch_event_rule" "order_created" {
  name = "order-created"
  event_bus_name = aws_cloudwatch_event_bus.orders.name
  event_pattern = jsonencode({
    "detail-type": ["OrderCreated"],
    "source": ["com.company.orders"]
  })
}

resource "aws_cloudwatch_event_target" "process_inventory" {
  rule = aws_cloudwatch_event_rule.order_created.name
  event_bus_name = aws_cloudwatch_event_bus.orders.name
  arn = aws_lambda_function.validate_inventory.arn
}

Публикация события из Lambda:

import boto3
import json
from datetime import datetime

events = boto3.client('events')

def publish_order_created(order: dict):
    events.put_events(
        Entries=[{
            'EventBusName': 'orders-bus',
            'Source': 'com.company.orders',
            'DetailType': 'OrderCreated',
            'Detail': json.dumps({
                'orderId': order['id'],
                'customerId': order['customer_id'],
                'items': order['items'],
                'totalAmount': order['total'],
                'timestamp': datetime.utcnow().isoformat()
            }),
            'Time': datetime.utcnow()
        }]
    )

SQS для надёжной доставки

EventBridge + SQS = отказоустойчивая доставка с retry и dead letter queue. Используем Terraform для инфраструктуры как кода:

resource "aws_sqs_queue" "inventory_updates" {
  name = "inventory-updates"
  visibility_timeout_seconds = 300
  redrive_policy = jsonencode({
    deadLetterTargetArn = aws_sqs_queue.inventory_dlq.arn
    maxReceiveCount = 3 # After 3 failures → DLQ
  })
}

resource "aws_lambda_event_source_mapping" "inventory_processor" {
  event_source_arn = aws_sqs_queue.inventory_updates.arn
  function_name = aws_lambda_function.process_inventory.arn
  batch_size = 10
  function_response_types = ["ReportBatchItemFailures"]
}

ReportBatchItemFailures — только неудачные сообщения возвращаются в очередь, успешные не повторяются.

Обработчик с partial failure

def handler(event, context):
    failed_message_ids = []
    for record in event['Records']:
        try:
            process_message(json.loads(record['body']))
        except Exception as e:
            # Только этот record пойдёт в retry, остальные — ОК
            failed_message_ids.append({'itemIdentifier': record['messageId']})
    return {'batchItemFailures': failed_message_ids}

Как обеспечить идемпотентность?

В event-driven системах события могут доставляться дважды (at-least-once delivery). Каждый обработчик должен быть идемпотентным. Используем DynamoDB как таблицу обработки с ConditionExpression:

import boto3
dynamodb = boto3.resource('dynamodb')
processed_events = dynamodb.Table('processed_events')

def handler(event, context):
    for record in event['Records']:
        event_id = record['messageId']
        # Проверить, не обработано ли событие уже
        try:
            processed_events.put_item(
                Item={'event_id': event_id, 'ttl': int(time.time()) + 86400},
                ConditionExpression='attribute_not_exists(event_id)'
            )
        except processed_events.meta.client.exceptions.ConditionalCheckFailedException:
            continue  # Already processed
        process_event(record)

Процесс внедрения

Внедрение event-driven архитектуры под ключ включает этапы:

Все этапы могут выполняться параллельно для разных компонентов. Сроки зависят от сложности бизнес-логики и количества сервисов. Средний проект — 14 рабочих дней.

Сравнение: event-driven vs микросервисы на REST

Мониторинг event-driven системы

Ключевые метрики:

• Event lag (SQS ApproximateAgeOfOldestMessage) — насколько свежие события обрабатываются
• DLQ depth — число событий в dead letter queue (ненулевое значение = проблема)
• Processing rate vs production rate — успевает ли система потреблять события
• End-to-end latency — время от события до результата через всю цепочку

Мы настраиваем CloudWatch alarms и дашборды, чтобы вовремя реагировать на отклонения. Опыт показывает: хороший мониторинг сокращает время реакции на инциденты в 2-3 раза.

Сколько времени занимает внедрение?

Сроки варьируются от 10 до 25 рабочих дней в зависимости от количества сервисов и сложности бизнес-логики. Оценим проект — пишите, мы подготовим детальный план и архитектурную схему.

Что входит в работу

Документация архитектуры и event schema, код Lambda-функций и инфраструктура как код (Terraform), настройка шин и очередей, реализация идемпотентности, мониторинг и алерты, тестовые скрипты, обучение команды. Мы даём гарантию на работоспособность решения в течение месяца после деплоя.

Закажите внедрение event-driven архитектуры — ваша система станет гибче и масштабируемее. Свяжитесь с нами для оценки вашего проекта, и мы подберём оптимальное решение.