Событийные паттерны

Асинхронная коммуникация между сервисами строится на Kafka и паттерне Transactional Outbox.

Transactional Outbox

Цель: гарантировать, что событие будет опубликовано в Kafka только если бизнес-транзакция успешно закоммичена (at-least-once доставка без 2PC).

API/Use case в одной транзакции с БД:
записывает бизнес-данные (например, пользователя);
записывает запись в таблицу outbox_events (topic, key, payload, status=PENDING).
Outbox Worker (отдельный процесс/поток):
периодически читает из outbox_events записи со статусом PENDING;
публикует их в Kafka;
помечает записи как PUBLISHED (или удаляет).

Библиотека: libs/python/storage/patterns/omni-box.
Таблица outbox_events партиционируется по времени (управление партициями — postgres-partition-manager).
Worker использует APScheduler или аналогичный планировщик для периодического опроса.

Потребители событий должны обрабатывать дубликаты (повторная доставка): по key или по event_id делать дедупликацию или идемпотентную обработку.

Топик	Producer	События	Consumers (planned)
`identity.user.events`	Identity service	USER_CREATED, USER_DISABLED, USER_ENABLED, USER_DELETED	Account service
`identity.identifier.events`	Identity service	IDENTIFIER_ADDED, IDENTIFIER_VERIFIED, IDENTIFIER_REMOVED	Herald (уведомления)
`credential.password.events`	Credential service	PASSWORD_SET, PASSWORD_CHANGED, PASSWORD_VERIFIED	Account, audit

Формат сообщений: ключ — идентификатор агрегата (например, user_id); тело — JSON с типом события, версией и payload.

Single consumer per partition — один consumer в группе обрабатывает партицию; масштабирование через число партиций.
Idempotent handler — обработчик по event_id или по ключу агрегата проверяет, не обработано ли уже событие.
Dead Letter Queue — при повторяющихся ошибках сообщение можно перенаправлять в DLQ для разбора и ручного replay.

На странице