Kafka: история действий сотрудников.
Внедрил общий журнал действий на HR-платформе: смены статусов кандидатов, загрузки документов, выгрузки отчётов и утверждения.
Исходная задача
На HR-платформе не было общего журнала действий сотрудников. Изменения статусов кандидатов, загрузки документов, выгрузки отчётов и утверждения требовалось собирать в единую историю, не добавляя синхронную запись журнала в каждую операцию.
Мой вклад
Я реализовал серверную часть журнала: создание audit-событий, публикацию из Outbox, Kafka consumer, отдельную PostgreSQL-базу истории и разграничение доступа к записям.
Инженерный подход
Изменение бизнес-данных и запись в Outbox сохранялись одной транзакцией; для выгрузки отчётов создавалось отдельное audit-событие. Publisher периодически читал Outbox и отправлял события в Kafka с ключом employee_id. Отдельный consumer записывал историю в PostgreSQL, защищаясь от дублей уникальным event_id (UUIDv7) и подтверждая offset после сохранения. Для загрузки паспорта в событии были только идентификатор, ссылка и метаданные, без самого файла. Ошибочные события попадали в отдельный Kafka topic для диагностики, без автоматического повторного запуска.
Результат
В production появился общий журнал действий с доступом по правам сотрудников. Основные операции завершались, не дожидаясь обновления истории, а накопленные в Outbox события обрабатывались после восстановления временно недоступных компонентов.
В этом кейсе результат — новая функция и разделение процессов, а не измеренное ускорение. Kafka использовалась отдельно от RabbitMQ. Ключ employee_id не гарантировал общий порядок изменений одного кандидата разными сотрудниками; DLQ служил для диагностики, а не для автоматического восстановления.