Архитектура и интеграции

Real-Time, Batch или Event-Driven: Выбор шаблона интеграции для Salesforce

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

Время чтения: 7 минОбновлено: 2026-07-30

Три ключевых вопроса, определяющих архитектуру интеграции, а не выбор инструмента

Часто при выборе интеграционного решения для Salesforce совершается ошибка, начиная с инструмента: будь то MuleSoft, Platform Events, Bulk API или простой Webhook. Инструмент — это следствие, а не отправная точка. Правильный подход определяется ответами на три следующих вопроса:

Насколько быстро целевая система должна получить информацию? Секунды, минуты, часы или дни — это определяет различие между режимами реального времени и пакетной обработки.
Кто является владельцем данных в любой момент времени? Если ответ на этот вопрос неоднозначен, ни одна техническая архитектура не решит проблему.
Что происходит, если целевая система недоступна? Ответ «подождем снова» не является решением. Необходимо определить четкое поведение: повторная попытка (Retry), постановка в очередь или явный отказ.

Те, кто отвечает на эти три вопроса до выбора технологии, почти всегда приходят к тому же выводу, что и опытный архитектор, но без затрат на эксперименты и ошибки в производственной среде. Подробное описание связи этого решения с общей архитектурой представлено в Руководстве по архитектуре CRM.

Карта шаблонов: когда какой шаблон уместен

Шаблон	Типичное время отклика	Типичный пример использования	Стоимость обслуживания	Основной риск
Синхронный Request-Reply	Миллисекунды до секунд	Проверка кредитоспособности перед одобрением транзакции	Средняя	Тайм-аут блокирует пользователя
Fire-and-Forget	Мгновенно при отправке, без ожидания результата	Отправка события для создания задачи в другой системе	Низкая-средняя	Тихий сбой без мониторинга
Периодическая пакетная обработка	Часы до суток	Синхронизация каталога продуктов раз в день из ERP	Низкая	Временные разрывы между системами
CDC (Change Data Capture)	Секунды до минут	Обновление статуса заказа, влияющее на поддержку	Средняя-высокая	Нагрузка на Event Bus при множественных изменениях
Event-Driven (Platform Events / Pub-Sub)	Секунды	Уведомление о бизнес-событии нескольким потребителям одновременно	Высокая при настройке, низкая при обслуживании	Требует дисциплины Schema и Versioning

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

Почему задержки недостаточно для принятия решения

Вторая распространенная ошибка: принимать решения исключительно на основе задержки (Latency), игнорируя согласованность (Consistency). Быстрый шаблон, который обновляет только одну сторону и оставляет другую «почти синхронизированной», создает более серьезную проблему, чем медленный, но согласованный шаблон. Пользователи учатся не доверять данным и обходят систему.

Правильный вопрос двойственен: насколько быстро требуется ответ и насколько критична ситуация, когда обе стороны на короткое время не синхронизированы. Процесс ценообразования, представленный клиенту, требует как скорости, так и полной согласованности — здесь необходим синхронный Request-Reply с определенным тайм-аутом и четкой обработкой сбоев. Обновление "количества просмотров статьи" может спокойно допускать задержку в несколько минут — здесь достаточно Fire-and-Forget или CDC.

Владение данными: решение, предшествующее любому шаблону

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

Практическое рабочее правило: для каждого общего поля назначается единственный владелец (Owner). Если существует реальная бизнес-потребность в редактировании с обеих сторон (например, служба поддержки клиентов обновляет адрес как в Salesforce, так и в ERP), добавляется явное правило разрешения конфликтов — последнее по времени изменение (Timestamp) побеждает, или одно поле является определяющим, а другое предназначено только для отображения. Управление разрешениями для таких чувствительных полей обсуждается в Руководстве по модели разрешений в Salesforce.

Обработка сбоев: тест, который большинство проектов пропускают

Почти каждая интеграция проходит тестирование «счастливого пути» (Happy Path). Лишь немногие проходят систематическую проверку на наличие трех следующих сценариев сбоев:

Вторая система недоступна во время отправки — сообщение сохраняется в очереди и отправляется снова, или теряется?
Сообщение приходит дважды (распространенная проблема при автоматическом повторе и в Event Bus) — получающая сторона создает дублирующую запись?
Сообщение приходит в некорректном порядке — приведет ли обновление статуса «отменено», пришедшее до статуса «одобрено», к неправильному результату?

Система, не построенная как идемпотентная (уникальный идентификатор для каждого сообщения + проверка на существование до создания), потерпит неудачу именно в двух первых сценариях, и зачастую под нагрузкой — то есть именно тогда, когда бизнес больше всего от нее зависит. Ограничения API и способы обработки троттлинга в этом контексте подробно описаны в Руководстве по лимитам API Salesforce.

Рамки принятия решений: от бизнес-вопроса к шаблону

Вопрос, задаваемый первым	Если ответ "Да"	Если ответ "Нет"
Пользователь ожидает результат интеграции на экране?	Синхронный Request-Reply с заданным тайм-аутом	Переходим к следующему вопросу
Требуется ли обновление в течение нескольких минут после единичного изменения?	CDC или Platform Event	Переходим к следующему вопросу
Нескольким различным потребителям необходимо знать об одном и том же событии?	Event-Driven с Pub-Sub	Переходим к следующему вопросу
Удобно ли обрабатывать большой объем в фиксированном временном окне?	Периодическая пакетная обработка	Рассмотреть Fire-and-Forget с очередью

Это отправная точка для обсуждения на архитектурном совещании, а не исчерпывающая формула — всегда есть пограничные случаи (например, огромный объем, требующий CDC, но также ежедневной пакетной сверки в качестве подстраховки).

Пример: сеть частных клиник с двадцатью филиалами

Рассмотрим сеть клиник, использующую Salesforce для управления запросами пациентов и отдельную систему биллинга, которую невозможно заменить на данном этапе. Требование: когда пациент завершает прием, система биллинга должна быть немедленно обновлена, и когда биллинг обновляется (например, получен платеж), Salesforce должна отражать это, чтобы представитель сервиса не запрашивал двойную оплату.

Первоначальный выбор команды – двусторонняя ночная пакетная обработка – был прост в реализации, но создавал разрыв до 24 часов, в течение которого представители видели устаревшую информацию, что приводило к жалобам. Фактическое решение: односторонняя синхронизация (завершение приема из Salesforce в биллинг) была переведена на Fire-and-Forget с очередью сообщений и автоматическим повтором, поскольку пользователю не нужно ждать результата. Вторая сторона (подтверждение оплаты из биллинга в Salesforce) была переведена на CDC, поскольку это точечное изменение, которое должно быть доставлено в течение нескольких минут. Ночная пакетная обработка осталась только как механизм сверки (Reconciliation) — ежедневное сравнение, выявляющее расхождения и генерирующее оповещения, а не как основной канал обновления.

Результат: время обновления сократилось с часов до минут, а механизм сверки выявил два случая потерянных сообщений в первый месяц — именно для этого он и предназначен.

Риски и конкретные меры предотвращения для интеграции

Риск	Как он проявляется на практике	Мера предотвращения
Отсутствие идемпотентности	Дублирующиеся записи после повтора или сетевого сбоя	Уникальный идентификатор сообщения + проверка существования перед созданием
Неопределенный источник истины	Цикл синхронизации или случайное «побеждающее» обновление	Назначенный владелец для каждого поля + правило разрешения конфликтов
Point-to-Point без уровня интеграции	Любое изменение схемы в одной системе ломает другое соединение	Уровень Middleware/API с четко определенным контрактом версий
Только технический мониторинг	Интеграция «зеленая», но заказы фактически отсутствуют	Бизнес-метрика сверки, а не только техническое время безотказной работы
Игнорирование Governor Limits	Интеграция рушится при пиковой нагрузке	Планирование Bulkification и Backoff заранее, а не как реакция

Чек-лист для выбора шаблона интеграции

☐ Требуемое время отклика определено в числах, а не словом «быстро»
☐ Определен единый владелец (Owner) для каждого общего поля между системами
☐ Проверено, что происходит, когда целевая система недоступна, — и задокументировано
☐ Проверено, что происходит, когда сообщение приходит дважды
☐ Проверено, что происходит, когда сообщения приходят в некорректном порядке
☐ Существует механизм сверки (Reconciliation), даже если основной шаблон асинхронный
☐ Ограничения API и Governor Limits проверены на соответствие ожидаемому объему при пиковой нагрузке
☐ Определены бизнес-метрики успеха, а не только технические

Метрики для постоянного мониторинга интеграции

После запуска целесообразно отслеживать всего три-четыре метрики: процент успешно обработанных сообщений с первой попытки, фактическое сквозное время относительно определенного SLA, ежедневные расхождения по сверке (Reconciliation) между системами и близость к лимитам API. Последовательный рост одного из этих показателей — а не однократное отклонение — является сигналом для рассмотрения перехода к другому шаблону, прежде чем система выйдет из строя в производственной среде. Вопросы идентичности и разрешений доступа между системами подробно описаны в Руководстве по SSO и идентичности в Salesforce.

Заключение

Выбор правильного шаблона интеграции начинается не с вопроса «какой инструмент», а с трех вопросов: насколько быстро требуется ответ, кто является владельцем данных и что происходит в случае сбоя. Real-Time подходит, когда пользователь ожидает результат; CDC и Event-Driven подходят для быстрого обновления единичных изменений или распространения нескольким потребителям; Batch подходит для больших объемов в фиксированном временном окне. В каждом шаблоне идемпотентность, определенное владение данными и механизм сверки — это не «было бы неплохо», а необходимое условие для того, чтобы интеграция выдержала реальную нагрузку, а не только демонстрацию.

Профессиональные источники

Salesforce Integration Patterns — https://architect.salesforce.com/docs/architect/fundamentals/guide/integration-patterns.html
Salesforce Data Integration Decision Guide — https://architect.salesforce.com/docs/architect/decision-guides/guide/data-integration.html
HPI Pro – Архитектура CRM — https://hpi.pro/crm-architecture
HPI Pro – Интеграции и данные — https://hpi.pro/integrations-data

Связанные статьи и услуги

Услуги по архитектуре CRM

Часто задаваемые вопросы

В чем практическая разница между Fire-and-Forget и Request-Reply при интеграции с Salesforce?

В паттерне Request-Reply вызывающая сторона ожидает ответа и немедленно получает подтверждение об успехе или неудаче операции — это подходит, когда пользователь работает с интерфейсом и ему нужен немедленный результат для продолжения. В Fire-and-Forget отправитель немедленно продолжает работу, а ответ, если он предусмотрен, приходит асинхронно — это подходит для обновлений, которые не блокируют человеческий процесс. Неправильный выбор приводит к тому, что пользователи ждут систему, которая не предназначена для ожидания, или упускают незаметные сбои.

Когда CDC предпочтительнее периодической пакетной обработки для синхронизации данных?

CDC (Change Data Capture) предпочтительнее, когда относительный объем изменений невелик по сравнению с общим объемом данных, и когда изменения необходимо отразить в течение минут, а не часов — например, обновление статуса заказа, влияющее на обслуживание клиентов. Пакетная обработка предпочтительнее, когда удобно обрабатывать большой объем данных в фиксированном временном окне, когда исходная система не поддерживает потоки событий, или когда сама обработка требует вычислений над полной группой записей, а не над отдельным изменением.

Как обрабатывать дублирующиеся сообщения в событийно-ориентированной интеграции?

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

Кто несет ответственность за источник истины, когда одно и то же поле обновляется как в Salesforce, так и во внешней системе?

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

Как понять, что выбранный шаблон интеграции все еще подходит после десятикратного увеличения нагрузки?

Проверяются три аспекта: соответствует ли время обработки установленному SLA, превысил ли процент отказов и повторных попыток заранее определенный порог, и приближаются ли к пределу ограничения API Salesforce (такие как Governor Limits или API Calls). Рост любого из этих показателей является сигналом для рассмотрения перехода от пакетной обработки к CDC, добавления очереди или распараллеливания процессов — прежде чем система выйдет из строя в производственной среде.

Следующий шаг

Хотите проверить архитектуру перед началом строительства?

Мы анализируем модель данных, модель разрешений и интеграции, а также выделяем решения, которые необходимо принять заранее.

Salesforce® и Agentforce® являются зарегистрированными товарными знаками Salesforce, Inc. HPI Pro — независимая консалтинговая компания. Содержание этой статьи является профессиональной информацией общего характера и не представляет собой индивидуальную консультацию для конкретной организации.