Впровадження 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 архітектури — ваша система стане гнучкішою та масштабованішою. Зв'яжіться з нами для оцінки вашого проекту, і ми підберемо оптимальне рішення.