Опишите договор между системами
До разработки фиксируют владельца данных, формат, частоту, допустимую задержку, объём, порядок изменений и способ подтверждения. Отдельно отвечают на вопрос: что произойдёт, если принимающая система недоступна час или обработает сообщение дважды?
Синхронный API нужен там, где ответ требуется сейчас
HTTP-сервис или REST/OData подходят для запроса актуальных данных и операций, результат которых нужен вызывающей системе немедленно. Но длинную бизнес-операцию нельзя удерживать внутри одного HTTP-запроса: сетевой тайм-аут не говорит, выполнилась она или нет.
Очередь отделяет приём от обработки
Асинхронный обмен полезен для больших потоков, нестабильных связей и операций, которые можно завершить позже. В 8.5.4 платформа получила механизм «Очередь», позволяющий отделять обязательное отложенное действие от синхронной части обработки документа.
Для очереди всё равно нужны идемпотентность, уникальный идентификатор сообщения, повторные попытки, карантин ошибочных сообщений и наблюдение за задержкой.
Регламентный обмен остаётся разумным выбором
Пакетная синхронизация удобна, если допустима задержка и данные естественно обрабатываются наборами. Она проще для сопровождения, но требует контроля окна, объёма, повторного запуска и конфликтов.
Защищайте рабочую базу от интеграционной нагрузки
Ограничивают частоту и объём запросов, используют пагинацию, не выдают интеграции лишние права и отделяют тяжёлую подготовку данных. Мониторинг должен показывать не только ошибку транспорта, но и бизнес-результат: сколько объектов принято, отклонено, повторено и сколько времени сообщение провело в очереди.