Что такое event-driven архитектура?

Event-Driven архитектура

Event-driven архитектура (событийно-управляемая архитектура) — это паттерн проектирования, в котором компоненты системы взаимодействуют путём производства, обнаружения и использования событий. Вместо прямых вызовов между модулями система работает через поток событий, что обеспечивает слабую связанность (loose coupling) и высокую масштабируемость.

Ключевые концепции

События — это сигналы об изменении состояния или выполнении действия. Например, пользователь нажал на кнопку, заказ создан, платёж прошёл.

Event Producer — компонент, который генерирует событие:

class OrderService:
    def __init__(self, event_bus):
        self.event_bus = event_bus
    
    def create_order(self, order_data):
        order = Order(**order_data)
        # ... сохранение заказа в БД ...
        
        # Испускаем событие
        self.event_bus.publish(OrderCreated(order_id=order.id))
        return order

Event Consumer — компонент, который реагирует на событие:

class EmailService:
    def __init__(self, event_bus):
        self.event_bus = event_bus
        # Подписываемся на событие
        self.event_bus.subscribe(OrderCreated, self.on_order_created)
    
    async def on_order_created(self, event: OrderCreated):
        # Отправить письмо покупателю
        await self.send_email(event.order_id)

Event Bus (Message Broker) — центральный компонент, который маршрутизирует события от продюсеров к консьюмерам. Может быть:

• In-process (простые приложения)
• RabbitMQ, Apache Kafka (распределённые системы)
• AWS SNS/SQS, Google Pub/Sub (облачные решения)

Преимущества

• Слабая связанность — сервисы не знают друг о друге
• Масштабируемость — легко добавлять новые обработчики событий
• Асинхронность — операции не блокируют друг друга
• Реактивность — система реагирует на события в реальном времени
• Отказоустойчивость — если обработчик падает, событие остаётся в очереди

Недостатки

• Сложность отладки — трудно отследить поток выполнения
• Гарантии доставки — нужна обработка дубликатов и потерь сообщений
• Консистентность данных — может быть временная несогласованность
• Overhead — дополнительная инфраструктура (очереди, брокеры)

Пример: Заказ и уведомления

from typing import Callable, List
from dataclasses import dataclass
from datetime import datetime

@dataclass
class OrderCreatedEvent:
    order_id: int
    customer_id: int
    timestamp: datetime

class SimpleEventBus:
    def __init__(self):
        self.subscribers: dict[type, List[Callable]] = {}
    
    def subscribe(self, event_type: type, handler: Callable):
        if event_type not in self.subscribers:
            self.subscribers[event_type] = []
        self.subscribers[event_type].append(handler)
    
    async def publish(self, event):
        handlers = self.subscribers.get(type(event), [])
        for handler in handlers:
            await handler(event)

# Использование
event_bus = SimpleEventBus()

async def send_confirmation_email(event: OrderCreatedEvent):
    print(f"Отправляю письмо для заказа {event.order_id}")

async def update_inventory(event: OrderCreatedEvent):
    print(f"Обновляю инвентарь для заказа {event.order_id}")

event_bus.subscribe(OrderCreatedEvent, send_confirmation_email)
event_bus.subscribe(OrderCreatedEvent, update_inventory)

# При создании заказа
event = OrderCreatedEvent(order_id=123, customer_id=456, timestamp=datetime.now())
await event_bus.publish(event)

Event-Driven vs CQRS

CQRS (Command Query Responsibility Segregation) часто идёт рука об руку с event-driven архитектурой. Commands изменяют состояние и генерируют события, а queries читают состояние из событийного лога.

Когда использовать

• Микросервисная архитектура
• Real-time уведомления и аналитика
• Высоконагруженные системы
• Системы с асинхронной обработкой
• IoT приложения

Event-driven архитектура требует продуманного подхода к обработке ошибок, повторным попыткам и гарантиям доставки, но при правильной реализации обеспечивает гибкую и масштабируемую систему.