Да! Вы можете голосовать за кейсы и присоединиться как слушатель.
Для участия в мероприятии необходимо заранее зарегистрироваться. Никаких специальных требований к участникам не предъявляется, главное — наличие интереса к решению практических задач.
Бесплатно!
Не переживайте, вы сможете подать его повторно на следующей встрече — возможно, тогда он получит больше голосов.
По желанию! Достаточно 5-минутного устного рассказа.
аналитик, тимлид и архитектор в одном лице, спец по оптимизации процессов и коммуникаций в команде
Елизавета Акманова
основатель онлайн-школы System Analyst, старший системный аналитик. Автор образовательных программ и ментор для аналитиков
Григорий Печенкин
ведущий аналитик ГК Юзтех, спикер и программный комитет на ИТ конференциях
соорганизатор ежегодных Летних Аналитических Фестивалей и Зимних Аналитических выходных, эксперт по процессам разработки ПО
Контакты
Электронная почта: analyst.club@yandex.ru
#1 Консистентность данных
Варианты решений
📚 Контекст Продуктовая команда клиентской поддержки обрабатывает обращения клиентов через контакт-центр (прием звонков и письменные обращения). Есть база данных, где хранится весь большой объект обращения. Есть BPM-движок, который управляет workflow обращения и хранит его промежуточные состояния. В самом BPM объекта обращения нет
😵💫 Проблема BPM с ощутимой задержкой обновляет данные по обращению в базе. Из-за этого появляются разрозненные данные и часть операторов могут видеть неактуальный статус клиентского обращения
❓Ключевой вопрос Как организовать консистентность данных из двух источников?
1. Оптимизация архитектуры данных и доступа
Единый источник истины для операций записи: все изменения статуса должны выполняться через один сервис, который атомарно обновляет и базу данных, и состояние процесса в Camunda
Блокировки на уровне БД (SELECT FOR UPDATE):при открытии обращения оператором база данных блокирует запись на время проверки и обновления статуса
2. Событийная архитектура и реальное время
Паттерн Pub-Sub: BPM-движок публикует событие об изменении статуса (например, в Redis или Kafka). Отдельный сервис-подписчик гарантированно обрабатывает это событие и обновляет базу данных
WebSocket для мгновенного обновления UI: При изменении статуса обращения в Camunda сервер отправляет через WebSocket сигнал всем подключенным клиентам (браузерам операторов). Интерфейс автоматически обновляет данные, показывая актуальный статус без необходимости перезагрузки страницы
Отображение активности операторов:Реализация функции "кто сейчас смотрит на обращение" (как в HH) предупредит коллег о том, что обращение уже находится в работе и его статус скоро изменится
3. Оптимизация процессов и логики
Автоматическое распределение обращений: Пересмотр бизнес-процесса: система автоматически назначает обращения свободным операторам по заданным правилам (round-robin). Это полностью исключает человеческий фактор
Объединение данных в запросах (JOIN): Для отображения обращения в интерфейсе данные запрашиваются одним запросом, который JOIN'ит основную информацию из базы и актуальный статус из таблицы процессов Camunda
Горизонтальное масштабирование: Увеличение количества экземпляров сервиса, отвечающего за синхронизацию данных, для уменьшения задержки между Camunda и БД.
4. Изменение роли BPM-движка
Camunda как оркестратор: BPM-движок отвечает только за управление маршрутом процесса, а вся бизнес-логика и данные хранятся в отдельных сервисах (репозиториях)