Встречи, на которых опытные аналитики помогут найти решения для ваших задач

Разбор кейсов с экспертами

Ближайшее мероприятие:
В ожидании...

Стать оффлайн участником
Планируется...

Как проходит

  • Сбор кейсов

    Отправьте свой кейс через короткую форму (это займет 5 минут)
  • Голосование и выбор кейса

    Подписывайтесь на наш Telegram-канал "Analyst club" и голосуйте за самые интересные кейсы
  • Разбор кейса на встрече

    Автор топ-кейса презентует задачу, а эксперты дают практические решения

Почему стоит участвовать

Реальные решения

Получите готовые решения для ваших задач от опытных аналитиков

Нетворкинг

Получите готовые решения для ваших задач от опытных аналитиков

Обмен опытом

Узнайте о подходах и решениях коллег из разных компани

Профессиональное развитие

Учитесь на реальных примерах и растите как эксперт
Прошедшие мероприятия

Ответы на вопросы

Организаторы

Юлия Литвинюк

Ольга Пономарева

аналитик, тимлид и архитектор в одном лице, спец по оптимизации процессов и коммуникаций в команде

Елизавета Акманова

основатель онлайн-школы 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-движок отвечает только за управление маршрутом процесса, а вся бизнес-логика и данные хранятся в отдельных сервисах (репозиториях)
Made on
Tilda