Короткий ответ: по расписанию — почти всегда, по событию — там, где задержка стоит денег, и почти никогда в чистом виде. Рабочая схема для большинства компаний — гибрид: срочное едет событиями, а раз в сутки расписание пересчитывает всё заново и добирает то, что не доехало.
Разница между схемами не в скорости, а в том, кто отвечает за факт доставки. При обмене по расписанию инициатор — ваша сторона: она приходит и спрашивает «что нового с прошлого раза». Пропустила один запуск — заберёт всё на следующем. При событийной схеме инициатор — чужая система: она стучится к вам сама, один раз, и если в этот момент ваш приёмник был недоступен, событие исчезает без следа.
Дальше — методика расчёта допустимой задержки, две сметы на одну и ту же задачу, расчёт цены окна на модельном интернет-магазине с 1 200 заказами в месяц и честный разбор трёх задач, где реальное время не нужно вообще. Базовые понятия — что такое вебхук, метод, лимит — мы разбирали в опорной статье про API и вебхуки, здесь они используются как известные.
Две схемы: кто кого будит
Обе схемы решают одну задачу — перенести изменение из системы А в систему Б. Отличаются они тем, кто начинает разговор, и из этого следует всё остальное: цена, поведение при сбое и то, что вы вообще способны заметить.
| Свойство | Обмен по расписанию | Обмен по событию |
|---|---|---|
| Кто начинает | Ваша сторона приходит и спрашивает «что нового» | Чужая система стучится к вам сама |
| Задержка | В среднем половина интервала: при 15 минутах — 7,5 минуты, максимум 15 | Секунды |
| Что будет, если запуск пропущен | Ничего: следующий запуск заберёт накопившееся | Событие потеряно навсегда, если нет подтверждения приёма |
| Что будет, если получатель лежал 40 минут | Данные догонят на ближайшем запуске | Всё, что пришло за эти 40 минут, потеряно |
| Расход лимитов чужого API | Постоянный: запросы идут, даже когда изменений нет | Экономный: трафик ровно по числу изменений |
| Поведение в пиковый день | Нагрузка ровная, растёт только объём одной пачки | Всплеск: 400 событий за 10 минут могут положить приёмник |
| Что нужно построить на вашей стороне | Запуск по времени и отметку «до какого момента забрано» | Постоянно доступный приёмник, очередь, повторы, защиту от дублей |
Главный практический вывод из таблицы — предпоследняя строка. Расписание умеет переживать сбои само, потому что состояние обмена хранится в одной отметке времени: «забрано всё до 14:45». Событийная схема этого свойства лишена по устройству, и всё, за что вы доплачиваете при переходе на неё, — это попытка вернуть свойство, которое у расписания было бесплатно.
Сравнение в две горизонтальные дорожки с общей красной вертикальной полосой посередине, подписанной «получатель недоступен 40 минут». Верхняя дорожка «По расписанию, каждые 15 минут»: стрелки-запросы через равные промежутки, три из них упираются в полосу и помечены «пусто», сразу после полосы одна стрелка уносит стопку из трёх пакетов с подписью «догнали, потерь нет». Нижняя дорожка «По событию»: три одиночные стрелки-капсулы входят в полосу и обрываются, рядом значок ошибки и подпись «3 события потеряно, никто не узнал». Справа общий вывод: «Расписание хранит одну отметку времени. Событию хранить нечего». Чертёжный стиль, подписи по-русски.
Сколько задержки вы можете себе позволить
Допустимая задержка — не свойство технологии, а свойство процесса. Она отсчитывается не от момента, когда данные изменились, а от момента, с которого задержка начинает стоить денег. Это разные точки, и путаница между ними — главный источник переплаты.
Пример. Заказ создан в 23:40, склад открывается в 9:00. Задержка обмена в 15 минут и задержка в 9 часов дают ровно один и тот же результат: сборка начнётся утром. Значит, для этого направления ночью допустимо любое окно, и «реальное время» здесь оплачивается не скоростью отгрузки, а спокойствием менеджера, который видит заказ на экране сразу.
| Что передаётся | От какого момента идёт отсчёт | Кто страдает при превышении | Разумное окно |
|---|---|---|---|
| Заявка с сайта в CRM | Нажатие кнопки «Отправить» — клиент уже ждёт звонка | Продажи: клиент уходит к тому, кто перезвонил первым | До 1 минуты |
| Остаток товара на сайт | Списание со склада в учётной системе | Клиент, оформивший заказ на то, чего уже нет | 15–60 минут |
| Оплата в учётную систему | Зачисление денег | Склад: товар не отпускают без отметки об оплате | 5–30 минут |
| Статус заказа клиенту | Смена статуса в учёте | Поддержка: звонки «где мой заказ» | 5–15 минут |
| Цены на сайт | Утверждение нового прайса | Маржа: продажи по старой цене | До суток, синхронно с прайсом |
| Данные в аналитику и дашборд | Конец суток | Никто, если отчёт смотрят утром | До суток |
| Выгрузка документов в бухгалтерию | Конец периода | Никто | До суток или до недели |
Заполните эту таблицу по своим направлениям обмена до первой встречи с подрядчиком. Обычно из шести-восьми строк требование «в реальном времени» остаётся справедливым для одной, максимум двух — и именно на них имеет смысл тратить событийную схему. Как формируются вилки по каждому типу работ, мы показываем в разделе бюджетов.
Цена окна: что стоит переход с часа на 15 минут
Дальше — числа. Модельная компания: интернет-магазин, 1 200 заказов в месяц, средний чек 6 400 ₽, маржа 22 %, то есть 1 408 ₽ с заказа. Остатки на сайт передаются из 1С:УТ. Считаем самое дорогое последствие задержки — оверселл, заказ на товар, которого уже нет.
Теперь тот же счёт для следующего шага. Переход с 15 минут на настоящее реальное время убирает не все оставшиеся 4 оверселла, а примерно 3: последний остаётся из-за одновременных заказов, от которых никакая частота обмена не спасает. Экономия — 3 × 1 071 = 3 213 ₽ в месяц. Держите это число в голове, читая следующий раздел: разница в поддержке между двумя схемами составит 13 000 ₽ в месяц.
Столбиковая диаграмма из трёх столбцов на 1 200 заказов в месяц. Ось Y — «оверселлов в месяц», значения 16, 4 и 1. Подписи столбцов: «раз в час», «раз в 15 минут», «по событию». Между первым и вторым столбцом дуга с подписью «−12 заказов, 12 852 ₽/мес, цена работ — 0 ₽». Между вторым и третьим — дуга с подписью «−3 заказа, 3 213 ₽/мес, цена работ — 164 000 ₽ и +13 000 ₽/мес». Под диаграммой строка: «Первый шаг бесплатный, второй — самый дорогой». Чертёжный стиль, подписи по-русски.
Во сколько раз дороже событийная схема
Одна и та же задача — два направления обмена между сайтом и 1С:УТ — в трёх вариантах. Строки надёжности здесь те же, что в разборе сметы на надёжную интеграцию, и цены по ним совпадают намеренно: это один и тот же набор работ, просто в разной комплектации.
| Строка работ | А. Расписание, 15 минут | Б. Только события | В. Гибрид |
|---|---|---|---|
| Обследование, карта полей, правила отказов | 26 000 ₽ | 26 000 ₽ | 26 000 ₽ |
| Два направления обмена по расписанию | 46 000 ₽ | — | — |
| Отметка «до какого момента забрано» и добор | 14 000 ₽ | — | — |
| Приёмник событий с подтверждением приёма | — | 38 000 ₽ | 38 000 ₽ |
| Очередь сообщений | — | 54 000 ₽ | 54 000 ₽ |
| Повторные попытки и ключ операции | — | 46 000 ₽ | 46 000 ₽ |
| Журнал обменов с поиском по номеру заявки | 22 000 ₽ | 58 000 ₽ | 58 000 ₽ |
| Мониторинг | 12 000 ₽ | 62 000 ₽ | 62 000 ₽ |
| Суточная сверка расписанием и добор пропущенного | — | — | 28 000 ₽ |
| Итого разово | 120 000 ₽ | 284 000 ₽ | 312 000 ₽ |
| Срок | 2 недели | 4 недели | 4–5 недель |
| Поддержка | 9 000 ₽/мес | 22 000 ₽/мес | 22 000 ₽/мес |
Чистая событийная схема дороже расписания в 2,4 раза, гибрид — в 2,6 раза. Но дело не в множителе, а в том, за что именно вы доплачиваете 164 000 ₽. Ни одна строка из этой разницы не делает обмен быстрее: приёмник, очередь, повторы, расширенный журнал и мониторинг нужны только для того, чтобы событийная схема не теряла данные. Скорость получается бесплатно, надёжность — за деньги.
Спросите: «Что произойдёт с событием, если в момент его отправки наш приёмник перезагружался?» Правильный ответ содержит слова очередь, подтверждение приёма и сверка. Ответ «такого не бывает, у нас всё надёжно» означает, что за 164 000 ₽ вы получите скорость без надёжности — то есть худший из трёх вариантов таблицы выше.
Гибрид: события для срочного, расписание для сверки
Гибрид собирается из двух независимых контуров, которые не знают друг о друге и поэтому не ломаются вместе. Быстрый контур гонит события и отвечает за скорость. Медленный контур раз в сутки проходит тот же участок целиком, сравнивает количества и добирает всё, чего не хватает. Второй контур не ускоряет ничего — он отвечает на вопрос «мы точно ничего не потеряли», и без него первый контур недоказуем.
- 1Быстрый контур: событие
Изменение в системе-источнике порождает событие. Приёмник принимает его, немедленно подтверждает приём и кладёт в очередь. Дальше очередь отдаёт сообщение обработчику, тот пишет документ в систему-получатель. Всё, что происходит после подтверждения приёма, отправителя уже не касается — и это единственный способ не терять события при кратких сбоях, разобранный подробно в статье про очереди и повторные попытки.
- 2Медленный контур: суточная сверка
Раз в сутки, обычно в 4 утра, запускается сверка: сколько заказов создано на сайте за прошлые сутки, сколько сделок появилось в CRM, сколько документов в учёте. Три числа должны сойтись с точностью до законных расхождений — отменённых, тестовых, объединённых заказов.
- 3Добор пропущенного
Если числа не сошлись, сверка не просто пишет в журнал, а сама забирает недостающие документы по расписанию — тем же способом, что вариант А. Именно поэтому в гибриде расписание не удаляют: оно остаётся как запасной путь доставки, а не только как контроль.
- 4Одно письмо в 9 утра
Результат сверки уходит одной строкой ответственному человеку в компании: «за сутки: сайт 41, CRM 41, учёт 41, расхождений нет». Письмо со словом «нет» приходит каждый день — это и есть доказательство, что обмен работает. Молчание доказательством не является.
Карта связей из пяти узлов в ряд: «Сайт», «Приёмник событий», «Очередь», «Обработчик», «1С:УТ». Верхняя линия — быстрый контур, сплошные стрелки с подписями на связях: «новый заказ» (Сайт → Приёмник), «подтверждение приёма за 0,2 с» (обратная стрелка), «сообщение в буфере» (Приёмник → Очередь), «повтор при отказе» (петля у Очереди), «документ заказа» (Обработчик → 1С:УТ). Нижняя линия — медленный контур, штриховая: широкая дуга от «1С:УТ» обратно к «Сайту» с подписью «суточная сверка в 4:00: сайт 41 — CRM 41 — учёт 41» и вторая штриховая стрелка «добор недостающих документов по расписанию». Сбоку врезка «Стоимость нижнего контура — 28 000 ₽ разово». Чертёжный стиль, подписи по-русски.
Когда событие не доехало и никто не узнал
Это главный неочевидный риск событийной схемы, и он не про аварии. Чужая система отправила вебхук один раз, ваш приёмник в эту секунду перезапускался после обновления, чужая система записала себе «отправлено» и больше не вернётся. Ни у кого нет ошибки: отправитель считает работу сделанной, получатель ничего не получал и потому не может об этом сообщить, а вы узнаёте о проблеме через три дня от клиента.
У сломанного обмена по расписанию есть возраст последнего успешного запуска, и он растёт — это видно. У потерянного события нет вообще никакого следа ни в одной из систем. Поэтому событийная схема без суточной сверки — это схема, про которую нельзя доказать, что она работает. Отсюда правило приёмки: не подписывайте акт, пока не увидите отчёт сверки хотя бы за неделю.
Три задачи, где реальное время не нужно вообще
Есть направления обмена, на которых событийная схема не даёт ничего, кроме счёта. Их полезно вычеркнуть из технического задания до того, как подрядчик посчитает по ним смету.
- 1Выгрузка документов в бухгалтерию. Учёт закрывается периодами, а не секундами: бухгалтер работает с закрытым месяцем и всё равно ждёт, пока период сформируется целиком. Событийная выгрузка здесь создаёт поток мелких правок в уже проведённые документы — то есть работу, а не экономию. Правильное окно — сутки, а перед закрытием периода — разовый полный пересчёт.
- 2Данные в аналитику и дашборды. Отчёт смотрят утром за вчера. Ночная выгрузка одной пачкой не только достаточна, но и лучше событийной: цифры в отчёте не меняются под руками у того, кто их обсуждает. Требование «дашборд в реальном времени» почти всегда означает «мы не доверяем цифрам», и решается это качеством справочников, а не частотой обмена.
- 3Обновление каталога и описаний товаров. Новая карточка, изменённое описание, новая фотография — всё это попадает на сайт после проверки человеком, и проверка занимает часы. Событийная схема здесь ускоряет доставку с 15 минут до 2 секунд внутри процесса, который в целом идёт полдня. Исключение — цена и остаток: они меняются без участия человека, и для них окно считают отдельно, как в таблице выше.
Горизонтальная шкала допустимой задержки с делениями: «1 минута», «15 минут», «1 час», «сутки», «неделя». На шкалу поставлены семь помеченных блоков: «Заявка с сайта в CRM» — на делении 1 минута; «Статус заказа клиенту» — между 5 и 15 минутами; «Оплата в учёт» — между 5 и 30 минутами; «Остаток на сайт» — между 15 и 60 минутами; «Цены на сайт» — на делении сутки; «Данные в аналитику» — на делении сутки; «Выгрузка в бухгалтерию» — между сутками и неделей. Зона левее 15 минут залита и подписана «здесь оправданы события, +164 000 ₽», остальная часть подписана «здесь достаточно расписания». Чертёжный стиль, подписи по-русски.
Что решает заказчик, а не подрядчик
Четыре решения по обмену подрядчик не может принять за вас, потому что это решения про деньги и ответственность, а не про технику. Их стоит зафиксировать письменно до начала работ — это те же вопросы, что попадают в требования к интеграции.
- Окно по каждому направлению. Не «в реальном времени», а конкретное число минут, и обоснование: кто и чем платит за его превышение.
- Что делать с изменением, которое опоздало. Заказ уже собран, а из CRM приехала правка адреса — перезаписывать, отклонять или звать человека. Ответ разный для адреса, состава заказа и цены.
- Кому уходит сигнал о расхождении в сверке. Конкретный человек в вашей компании с именем, а не «в поддержку». У этого человека должно быть право остановить отгрузку.
- Приёмлемое время недоступности вашего приёмника. Из него следует, нужен ли резервный узел. Обычно достаточно очереди и повторов, но решение принимает тот, кто платит за простой.
Когда событийная схема не нужна
Пять ситуаций, в которых мы сами отговариваем от событий и предлагаем расписание с коротким окном. Все они проверяются до подписания договора.
- Ни на одном направлении окно не меньше 15 минут. Тогда доплата 164 000 ₽ и 13 000 ₽/мес покупает разницу, которую в модельном примере оценили в 3 213 ₽/мес. Это не окупится ни за какой срок.
- У чужой системы нет вебхуков. Половина российских учётных систем и часть отраслевых сервисов их просто не отдают. Событийную схему тогда имитируют частым опросом — это то же расписание, только с ускоренным расходом лимита чужого API. Честнее называть вещи своими именами и настроить опрос раз в 2–5 минут.
- Меньше 150 операций в месяц. Приёмник, очередь и мониторинг стоят одинаково при 150 и при 3 600 событиях. На малом потоке цена одной операции становится неприличной; при таких объёмах иногда дешевле обмен файлом по расписанию.
- Нет никого, кто прочитает письмо сверки. Событийная схема требует человека, который каждое утро смотрит три числа и звонит, когда они не сошлись. Если такого человека нет и не будет, событийный контур превратится в чёрный ящик, и потери в нём будут больше, чем при расписании.
- Обмен между двумя вашими же системами внутри одной сети. Здесь запуск раз в минуту стоит копейки и не создаёт нагрузки: чужих лимитов нет, сеть своя. Событийная сложность окупается там, где на том конце чужая система с ограничениями, а не там, где две ваши базы стоят в одной стойке.
И последнее. Спор «расписание против событий» почти всегда ведут не о том. Разница в задержке между аккуратным 5-минутным расписанием и событийной схемой — минуты, и она редко стоит денег. Разница в полноте данных между схемой со сверкой и схемой без неё — это заказы, которых нет в учёте, и она стоит денег всегда. Поэтому правильный первый вопрос к подрядчику не «сделаете в реальном времени?», а «как я узнаю, что за вчера ничего не потерялось?».
Скорость обмена видно на демонстрации. Полноту обмена видно только на сверке — или через три дня по звонку клиента.
