Двусторонняя синхронизация данных: источник истины и разрешение конфликтов

Двусторонняя синхронизация данных нужна не для механического копирования всех полей в обе стороны. Её задача — сохранить согласованные значения, когда сотрудники и автоматические процессы меняют одну сущность в разных системах. Для этого заранее назначают источник истины для каждого поля, проверяют версию записи, отделяют новое событие от echo и передают неоднозначный конфликт человеку.

Ниже — проектная схема и синтетический пример. Это не результат клиента Switch On AI и не отчёт о запуске в реальных CRM. Возможности конкретной пары систем, API, прав и тарифа нужно проверить до разработки.

Какую задачу решает этот процесс

Операционный директор видит практическую проблему: менеджер исправляет телефон контакта в CRM A, сотрудник договорного отдела меняет статус того же договора в системе B, а интеграция по очереди переносит обе записи. Если обмен устроен как безусловная перезапись, запоздавшее событие может вернуть старый телефон или прежний статус.

Интегратору CRM нужно добиться другого результата: каждое изменение проходит по правилам конкретного поля. Система принимает актуальное событие, отклоняет устаревшее, не размножает обратное echo и сохраняет спорную правку для разбора. Согласованность достигается после обработки событий и исключений, а не обязательно в ту же секунду.

Речь идёт о постоянном обмене после внедрения, в том числе при одновременных изменениях. Это не разовая миграция CRM и не инструкция к одному коннектору. При миграции записи переносят один раз и проверяют итоговый набор. При синхронизации те же правила применяются к каждому следующему событию, повтору и удалению.

Какие данные и правила подготовить

До выбора инструмента опишите сущность и её жизненный цикл. Одного mapping полей недостаточно: интеграции нужны признаки, по которым она отличит свежее изменение от старого и удаление от временно пустого значения.

Обязательные данные:

• устойчивый ID сущности в обеих системах и таблица соответствий между ними;
• версия сущности или поля, которую можно сравнить при записи;
• владелец каждого синхронизируемого поля;
• направление передачи и правило конфликта;
• журнал с идентификатором события, исходным значением, решением и результатом обработки.

Условные данные:

• timestamp, если системы передают время в сопоставимом формате;
• origin, если источник события можно сохранить или восстановить;
• tombstone, если удаление должно распространяться между системами;
• соответствия справочников: например, «Подписан» в B соответствует определённому коду статуса в A.

Неизвестное до обследования: поддержка условной записи, точность часов, доступные webhooks, идентификатор события, правила удаления, права и тарифные ограничения API. Ответственный за интеграцию проверяет технические свойства, а владелец процесса утверждает смысл полей и допустимые решения при конфликте.

Короткий заполненный образец ниже полностью синтетический:

Для каждого поля фиксируют не только технический источник, но и человека, который вправе менять правило. Иначе интегратор сможет настроить передачу, но не сможет решить, какое из двух содержательно разных значений считать правильным.

Как назначить источник истины для каждого поля

Нельзя объявить обе системы безусловно главными для одного поля. Если телефон принадлежит CRM A, изменение из B не должно молча перезаписывать его. Если статус договора ведёт система B, CRM A получает этот статус, но не становится его вторым владельцем.

Рабочая матрица для условной сущности выглядит так:

Совместное редактирование email не означает, что обе системы одновременно являются источником истины. Оно означает отдельный процесс принятия решения: несовпадающие параллельные изменения останавливаются, сохраняются и передаются человеку.

При разовой миграции владелец нужен прежде всего для выбора исходного набора и приёмки переноса. При постоянной синхронизации матрица действует после запуска: для каждого нового события, повтора, конфликта и удаления.

Как разрешать одновременные изменения

Для синтетического примера выберем оптимистическую условную запись как проектное правило. Событие несёт base_version, то есть версию, которую отправитель прочитал перед изменением. Запись разрешается, только если текущая версия всё ещё совпадает с базовой:

current_version = base_version → записать значение и установить version_new = current_version + 1.

Если версии различаются, интеграция не должна угадывать. Она сохраняет входное и текущее значения, ID сущности, источники событий и версии, затем создаёт конфликт для человека.

Синтетический расчёт для email:

1. Обе системы прочитали old@example.test в версии 7.
2. Событие A первым записало a@example.test: условие 7 = 7 выполнено, новая версия — 8.
3. Событие B несёт b@example.test и прежнюю base_version=7.
4. Проверка даёт current_version 8 ≠ base_version 7. Перезапись запрещена.
5. Email остаётся a@example.test в версии 8, а b@example.test сохраняется в записи конфликта до решения человека.

После выбора человек записывает утверждённое значение как новую версию 9. В журнале остаются автор решения и обе исходные правки.

Last-write-wins допустим только как отдельно согласованное правило. Формально победителя можно выбирать по максимальному event_time, а при равном времени — по заранее установленному приоритету источника. Но рассинхронизация часов способна сделать позднейшее время ложным признаком свежести, а содержательно правильное значение будет потеряно. Поэтому в учебном конфликте email это правило не применяется. Timestamp служит журналу; основное решение опирается на версию и условную запись.

Как не создать петлю обновлений

Без защиты обычное изменение из A попадёт в B, B сформирует новое событие, а A снова воспримет его как пользовательскую правку. Получится петля, хотя значение уже совпадает.

Связанная защита состоит из нескольких правил:

1. Первичное событие получает идемпотентный ключ операции: operation_id = origin + origin_event_id.
2. При передаче в другую систему интеграция сохраняет operation_id и origin; локальный ID нового уведомления хранится отдельно.
3. Уже обработанный operation_id повторно не меняет запись.
4. В журнале сохраняется origin — первоначальный источник изменения.
5. Перед записью значения нормализуются и сравниваются.
6. Если normalize(incoming) = normalize(current), интеграция не создаёт новую запись и исходящее событие.

Для телефона в синтетическом примере действует конкретное правило нормализации: удалить пробелы, скобки и дефисы, а ведущую 8 заменить на +7. Поэтому 8 (999) 123-45-67 и +7 999 1234567 сравниваются как +79991234567. Это лишь учебное правило; допустимые форматы и страны нужно определить для реальных данных.

Удаление передают не пустым полем, а tombstone: entity_id, deleted=true, deleted_at, version и origin. Физическое удаление откладывают на согласованный срок. Тогда запоздавшее событие с меньшей версией не воскресит сущность. Частоту очистки и срок хранения определяют при внедрении, а не берут из универсального шаблона.

Периодическая сверка сопоставляет ID, версии, признак удаления и нормализованные значения. Она находит события, которые не дошли через основной канал. Интервал сверки зависит от допустимой задержки и ограничений API.

Учебный пример: путь от входных данных до результата

Все ID, версии, телефоны, адреса и названия статусов ниже условные. Это синтетическая проверка проектных правил, а не файл клиента и не результат работающей интеграции.

Исходная сущность имеет соответствие A-104 ↔ B-778. Телефон +79991234567 находится в версии 11, статус договора «Черновик» — в версии 7, email old@example.test — в версии 7.

Далее происходят четыре события:

1. A1: CRM A меняет телефон на 8 (999) 765-43-21 при base_version=11. Текущая версия равна 11, поэтому интеграция сохраняет нормализованное значение +79997654321, создаёт версию 12 и передаёт её из A в B.
2. B1: система B меняет статус на «Подписан» при base_version=7. Проверка 7 = 7 разрешает запись версии 8 и передачу из B в A.
3. A2 и B2: обе системы меняют email, прочитав версию 7. A2 обрабатывается первой и создаёт версию 8 со значением a@example.test. B2 приносит b@example.test с base_version=7; условие 8 ≠ 7 создаёт конфликт вместо перезаписи.
4. Echo A1: событие о телефоне возвращается из B с сохранёнными operation_id и origin=A. Журнал уже содержит этот ключ операции, поэтому интеграция не создаёт новых обновлений.

Пример показывает три разных результата: независимые поля проходят в своих направлениях, спорное поле ждёт человека, а обратное echo не запускает новый цикл.

Как проверить результат перед запуском

Проверку проводят на искусственных записях без клиентских данных. Для каждого сценария заранее фиксируют ожидаемый результат, сигнал ошибки и действие человека. Сам факт успешной передачи одной записи не подтверждает готовность всей синхронизации.

Отдельно проверьте рассинхронизацию времени. Бизнес-решение не должно зависеть только от локального timestamp: сравнивайте версии и условие записи. Если часы расходятся сильнее согласованного допуска, создавайте сигнал и направляйте событие на разбор. Более поздняя отметка времени сама по себе не доказывает, что данные свежее.

Не обещайте мгновенную согласованность. Укажите допустимую задержку, поведение очереди при недоступности системы, число повторов и условие передачи человеку. Значения сравнивайте после одной и той же нормализации с обеих сторон.

В документации HubSpot Data Sync для поддерживаемых приложений описаны одно- и двустороннее направления, mapping полей, внутренний индекс записей и сравнение изменений. Это подтверждает общий класс готовых инструментов, но не совместимость с любой CRM и не правила учебного алгоритма выше. Поддерживаемые объекты, разрешение конфликтов, права и тариф нужно сверять для конкретного подключения.

Что согласовать для внедрения

Готовый инструмент подходит, если он поддерживает нужную пару систем, объекты, направления, mapping и приемлемое правило конфликта. Его границы нельзя определять только по названию функции «двусторонняя синхронизация»: отдельно проверяют доступные поля, права, тариф, удаление, задержку, журнал и поведение при сбое.

Собственная интеграция нужна, когда процесс требует поля-владельцы, условную запись по версии, очередь конфликтов, особую нормализацию, tombstone или сверку, которых нет в готовом подключении. Это не делает собственную разработку обязательной: решение принимают после проверки данных и API. Для смежного примера подключения можно посмотреть руководство по n8n и Битрикс24, не перенося его настройки на другую пару систем без проверки.

Switch On AI разрабатывает ИИ-помощника, бота или интеграцию для конкретной операции после проверки данных и API. В описанном сценарии обычная интеграция должна обеспечить результат: одинаковая сущность не перезаписывается устаревшими данными между системами. ИИ-помощник или бот нужен только в том случае, если в процессе действительно есть диалог, поиск сведений или разрешённое действие для пользователя; эти форматы не заменяют контроль версий.

Правила бухгалтерского, юридического, кадрового и отраслевого учёта задаёт и проверяет специалист заказчика. Упоминание HubSpot или другого вендора не доказывает партнёрство, выполненное внедрение или совместимость с вашей системой. Права, тарифы и доступные API проверяются отдельно. Работа с 1С в этот объём не входит.

Чтобы предметно обсудить прототип, подготовьте пару систем и один обезличенный пример конфликтующей записи: ID, исходные значения, версии, владельцев полей и ожидаемое решение. Затем можно разобрать одну операцию и согласовать прототип. Прототип проверяет выбранный сценарий, но не равен полному внедрению и не обещает заранее заданный эффект или срок.