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

Читать данные для:

аналитики;

сверки;

миграции;

CDC;

отчётности —

может быть вполне рационально.

Писать напрямую в таблицы стороннего приложения — уже другой риск.

Можно обойти:

валидацию;

транзакционные правила;

audit;

бизнес-события;

пересчёты;

security layer.

Поэтому AMPE не считает наличие доступа к БД достаточным основанием для прямой записи.

Таблицы отражают внутреннюю реализацию.

View может стать стабильным read-contract.

Она:

прячет внутренние детали;

фиксирует набор полей;

нормализует названия;

ограничивает доступ;

позволяет менять внутреннюю схему с меньшим влиянием на потребителя.

Для многих legacy-интеграций это уже значительное улучшение.

CDC сообщает: данные изменились.

Business event сообщает: произошло значимое событие.

UPDATE в таблице может означать:

новый статус заказа;

технический timestamp;

фоновые вычисления;

служебную коррекцию.

AMPE использует CDC там, где технический поток изменений действительно нужен, и при необходимости добавляет слой интерпретации.

Если:

изменения редкие;

объём небольшой;

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

система не умеет events —

incremental polling по watermark может быть очень надёжным.

Проблема не в polling.

Проблема в бесконтрольном full scan, неясных границах и отсутствии механизма восстановления.

Read replica может разгрузить production от аналитических и интеграционных запросов.

Но нужно учитывать replication lag.

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

Для проверки только что созданного резерва — уже нет.

AMPE выбирает источник чтения по требованию к freshness.

Одна БД напрямую выполняет запрос к другой.

Это удобно.

Но теперь:

доступность одной влияет на вторую;

запрос может блокировать удалённый ресурс;

schema change ломает consumer;

security boundary становится сложнее.

Мы используем такие механизмы только там, где их цена осознанна.

Добавили колонку — обычно безопасно.

Переименовали — уже нет.

Изменили смысл — ещё опаснее.

AMPE отделяет internal schema lifecycle от external data contract там, где интеграция должна жить долго.

Вместо прямой записи в бизнес-таблицы можно использовать staging.

Внешняя система кладёт данные в контролируемую зону.

Приложение валидирует и применяет их собственной логикой.

Так database transport остаётся, но бизнес-правила не обходятся.

Даже хороший поток может столкнуться с:

ручной корректировкой;

пропущенной записью;

ошибкой mapping;

replay;

сбоем после частичной обработки.

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

ID=123 в одной системе ничего не означает для другой.

Нужен:

external ID;

UUID;

business key;

mapping table;

другой устойчивый способ связать объекты.

Иначе интеграция начинает зависеть от случайных внутренних ключей.

Сначала определяется допустимая роль БД в обмене.

Затем — read/write boundary.

Для чтения создаётся стабильное представление или поток изменений.

Для записи — контролируемая точка применения.

Quality checks, lineage и reconciliation обеспечивают доверие к данным.

Так прямой доступ к БД перестаёт быть скрытым обходом архитектуры.

Интеграционные запросы меньше вредят production.

Внутренняя схема меньше становится внешним контрактом.

Прямая запись используется только осознанно.

CDC и polling применяются по реальной задаче.

Изменения данных легче трассировать.

И главное — database integration остаётся техническим механизмом, а не способом случайно связать две системы навсегда.