Синхронизация — это не «сделать так, чтобы везде было одинаково»

Имя клиента может редактироваться в CRM.

Юридические реквизиты — в ERP.

Классификатор — в MDM.

Фактический остаток — в WMS.

Если этот ownership не определён, двусторонний обмен быстро превращается в цикл взаимных перезаписей.

Одна система публикует факт.

Другая принимает.

Нет вопроса «кто победит при конфликте».

Поэтому AMPE не делает bi-directional sync автоматически только потому, что обе системы технически умеют изменять поле.

Два изменения произошли почти одновременно.

Что важнее?

Последняя запись?

Authoritative system?

Ручное разрешение?

Merge?

Для разных типов данных ответ разный.

«Last write wins» прост технически и может быть совершенно неверен бизнесово.

Полная синхронизация проста для небольших наборов.

На больших объёмах она создаёт лишнюю нагрузку.

Incremental sync использует:

updated_at;

sequence;

CDC;

events;

change token;

другой watermark.

AMPE выбирает механизм по объёму, latency и надёжности источника изменений.

Часы разных серверов могут расходиться.

Несколько записей получают одинаковое время.

Транзакция зафиксировалась позже.

Поле updated_at может вообще не обновляться для некоторых изменений.

Поэтому мы проверяем семантику источника, прежде чем строить на timestamp гарантию полноты.

Объект исчез.

Как другая система об этом узнает?

Hard delete может быть невидим для polling после факта.

Поэтому используются:

soft delete;

tombstone;

event;

CDC;

отдельный журнал изменений.

Если удаления не учтены, системы постепенно начинают хранить разные наборы объектов.

Сначала нужно передать текущее состояние.

Потом начать обрабатывать новые изменения.

Между snapshot и incremental flow не должно образоваться окно потери.

AMPE отдельно проектирует initial load, cutover и момент включения delta-потока.

CRM customer 725.

ERP counterparty 10483.

MDM party UUID.

Это один объект?

Mapping должен быть устойчивым и сохраняться независимо от изменения названий или реквизитов.

Справочник страны меняется редко.

Остаток — постоянно.

Профиль клиента — время от времени.

Статус заказа — событийно.

Для каждого класса данных нужен свой SLA, direction и recovery model.

Обновление оргструктуры через пять минут может быть нормально.

Остаток перед обещанием клиенту — нет.

AMPE связывает frequency sync с бизнес-ценой устаревания, а не со стремлением сделать всё «в реальном времени».

Даже при хорошей доставке возможны:

ручные правки;

старые баги;

частично обработанные batch;

изменение mapping;

ошибка source system.

Периодическая сверка отвечает на вопрос: действительно ли системы продолжают соглашаться по критическим данным.

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

AMPE отделяет:

transport;

mapping;

validation;

quality;

governance.

Быстрая доставка плохих данных не является успехом.

Для каждого объекта определяется owner.

Фиксируется направление обмена.

Выбирается механизм capture изменений.

Mapping связывает identities.

Processing применяется идемпотентно.

Conflicts получают правило.

Reconciliation проверяет фактическую согласованность.

Так sync становится управляемой системой, а не вечным набором скриптов.

Системы меньше перезаписывают друг друга.

Ownership становится понятным.

Потери изменений легче обнаружить.

Initial load не смешивается с ежедневным delta-flow.

Удаления и конфликты получают явную логику.

Reconciliation показывает реальную согласованность.

И главное — синхронизация перестаёт означать «копировать всё» и начинает означать «поддерживать правильное состояние там, где оно нужно».