Односторонний и двусторонний обмен: что выбрать

Не выбирайте направление для всей системы сразу

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

Формулировка «полная синхронизация» слишком неопределённа для оценки. Она не объясняет, что делать, если менеджер изменил телефон в CRM, а клиент одновременно обновил его в кабинете. Правила такого столкновения относятся к бизнес-смыслу, а не только к технологии передачи. Их нужно согласовать до подключения API.

Сравните схемы по ответственности

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

Определите правило конфликта

Варианты включают приоритет источника, сравнение версии, согласование человеком или предметное объединение отдельных полей. Простое «последнее по времени побеждает» требует доверенного порядка и не всегда отражает более правильное значение. Часы систем могут отличаться, а поздняя доставка не означает позднее изменение. Укажите, какое время и какая версия используются.

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

Защитите обмен от циклов

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

Идемпотентность защищает от повторного эффекта одной операции, но сама по себе не определяет правильную версию. Порядок и конфликты — отдельные задачи. Аналогично webhook сообщает о событии, но не гарантирует, что данные автоматически согласуются. Выбор транспорта не заменяет правила владельца.

Опишите отсутствие, удаление и восстановление

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

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

Учебный пример клиента и сделки

Сайт создаёт обращение и передаёт контакт, CRM назначает ответственного и ведёт этап продажи. Кабинет получает разрешённый статус, но не перезаписывает его своей копией. Если клиент меняет телефон, отдельный процесс решает, обновляет ли он общий контакт или только данные конкретного обращения. Это две разные модели с разными последствиями.

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

Как зафиксировать выбранную схему

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

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

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

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