Событийно-ориентированная архитектура: Паттерны, преимущества и типичные ошибки

Когда системы перерастают одиночный сервис и одну базу данных, синхронная модель запрос-ответ становится обузой. Сервисы становятся тесно связанными, отказы каскадируются непредсказуемо, а независимое масштабирование компонентов становится почти невозможным. Событийно-ориентированная архитектура (EDA) решает эти проблемы, инвертируя модель коммуникации: вместо прямых вызовов сервисы генерируют события, которые другие сервисы потребляют асинхронно. Это обеспечивает независимое масштабирование и изоляцию отказов, но вносит сложность в упорядочение, консистентность и наблюдаемость.

Event Sourcing и CQRS

Event sourcing идёт дальше, делая события первичным источником истины. Вместо хранения текущего состояния сущности в строке БД вы храните полную последовательность событий. CQRS естественно сочетается с event sourcing, разделяя модель записи (хранилище событий) и модели чтения (материализованные представления). Операции записи добавляют события в хранилище, а проекции асинхронно строят оптимизированные для чтения представления.

Выбор брокера сообщений: Kafka vs. RabbitMQ

Выбор между Apache Kafka и RabbitMQ отражает принципиально разные философии обмена сообщениями. Kafka — распределённый commit log, где сообщения сохраняются на диск в упорядоченных неизменяемых партициях. RabbitMQ — традиционный брокер, реализующий AMQP, маршрутизирующий сообщения через exchange'и в очереди. На практике многие продакшен-архитектуры используют оба: Kafka как основную шину событий, RabbitMQ для очередей задач и сложной маршрутизации.

Обработка сбоев: очереди мёртвых писем и идемпотентные потребители

В распределённой событийной системе сбой — не исключение, а константа. Dead letter queues (DLQ) обеспечивают страховку для сообщений, которые не удалось обработать после настраиваемого числа попыток. Не менее критична идемпотентность потребителей: поскольку доставка в распределённых системах по сути «хотя бы однократная», каждый потребитель должен корректно обрабатывать дублированные сообщения. Стандартный подход — включение уникального event ID и ведение хранилища ключей идемпотентности.

Операционные ошибки, которых следует избегать