Проекты, где 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 архитектуры под ключ включает этапы:
| Этап | Сроки |
|---|---|
| Проектирование event schema + шины | 2–3 дня |
| EventBridge настройка + правила маршрутизации | 2–3 дня |
| SQS + DLQ + Lambda event sources | 2–3 дня |
| Идемпотентность обработчиков | 2–4 дня |
| Distributed tracing + мониторинг | 2–3 дня |
| Интеграционное тестирование | 2–4 дня |
Все этапы могут выполняться параллельно для разных компонентов. Сроки зависят от сложности бизнес-логики и количества сервисов. Средний проект — 14 рабочих дней.
Сравнение: event-driven vs микросервисы на REST
Таблица сравнения
| Параметр | Event-Driven (AWS) | REST Микросервисы |
|---|---|---|
| Связанность | Слабая (через события) | Сильная (прямые вызовы) |
| Отказоустойчивость | Встроенные ретраи, DLQ | Ручная обработка, circuit breaker |
| Масштабирование | Независимое, per consumer | Требует синхронизации |
| Добавление нового сервиса | Подписка без изменений | Часто правка API gateway |
| Задержка | ~100 мс (EventBridge) | ~10 мс (прямой вызов) |
Мониторинг 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 архитектуры — ваша система станет гибче и масштабируемее. Свяжитесь с нами для оценки вашего проекта, и мы подберём оптимальное решение.