Шины и события

Безлюдный бизнес-движок — это не набор систем, а прежде всего связи между ними. Учёт, CRM, биллинг, HR-контур, документооборот нескольких юрлиц и десятки AI-агентов должны обмениваться данными без человека-«переносчика Excel-файлов». Эта глава даёт язык и инженерную механику интеграции: как человечество прошло путь от точечных стыковок к сервисным шинам и обратно к «умным конечным точкам и глупым трубам», какие паттерны из книги Хоупи и Вульфа остаются азбукой интеграции двадцать с лишним лет спустя, чем событийная архитектура отличается от запросно-ответной и почему для компании без операторов гарантии доставки и идемпотентность — вопрос выживания, а не тонкой настройки. Мы разберём Kafka как «центральную нервную систему», паттерны saga и outbox, схемные контракты, iPaaS-инструменты для «интеграции гражданами» и новейший слой — протоколы MCP и A2A, превращающие AI-агента в полноправного интеграционного клиента. Задача главы — дать методологическую основу, чтобы спроектировать минимально достаточную интеграционную ткань холдинга: не «энтерпрайз ради энтерпрайза», но и не хрупкую паутину Zapier-связок, которая развалится при первом масштабировании.

6.1. Краткая история интеграции: от «спагетти» к шине и обратно

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

Point-to-point: комбинаторный взрыв

Первая эпоха — точечные интеграции (point-to-point). Каждая пара систем, которой нужно обмениваться данными, соединяется отдельным «проводом»: выгрузка из бухгалтерии в CRM, скрипт из CRM в биллинг, ночной FTP-обмен между складом и сайтом. Пока систем три, всё выглядит невинно. Но число потенциальных связей растёт квадратично: при N системах — до N×(N−1)/2 соединений. Десять систем — сорок пять возможных стыковок, каждая со своим форматом, расписанием, обработкой ошибок и автором, который уже уволился. В индустрии это состояние получило имя «спагетти-интеграция» или «big ball of mud» применительно к ландшафту. Ключевая проблема даже не в количестве, а в связанности (coupling): каждая интеграция знает внутреннее устройство обеих сторон, и замена любой системы означает переписывание всех её «проводов».

EAI и брокеры: hub-and-spoke

Вторая эпоха — EAI (Enterprise Application Integration), конец 1990-х. Идея: вместо N² связей поставить в центр брокера сообщений (message broker) — TIBCO, IBM MQSeries, Microsoft BizTalk, webMethods. Каждая система соединяется только с хабом (топология hub-and-spoke), хаб маршрутизирует и трансформирует сообщения. Число соединений падает до N, появляется единая точка мониторинга. Плата — единая точка отказа и, что важнее, единая точка организационного удушья: все изменения проходят через центральную команду интеграции, которая быстро становится бутылочным горлышком.

ESB и SOA: шина как церковь

Третья эпоха — сервис-ориентированная архитектура (SOA, Service-Oriented Architecture) и её флагманский артефакт — сервисная шина предприятия (ESB, Enterprise Service Bus), 2002–2012. Замысел был красив: все системы публикуют свои функции как сервисы (обычно SOAP/WSDL), а шина — Oracle Service Bus, IBM WebSphere ESB, MuleSoft, TIBCO — берёт на себя маршрутизацию, трансформацию, оркестрацию (BPEL-процессы), безопасность и мониторинг. Шина обещала «канонический» слой: подключил систему один раз — и она интегрирована со всеми.

Почему ESB умер — точнее, почему умерла его идеология (сами продукты живы во многих банках до сих пор)? Разбор полёта даёт несколько причин, и все они актуальны как предостережение:

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

во-вторых, организационное горлышко. Одна команда ESB обслуживала запросы десятков продуктовых команд. Очередь на «заведение сервиса в шину» измерялась неделями; SOA-комитеты по каноническим моделям заседали месяцами. Скорость поставки, ради которой всё затевалось, падала.

в-третьих, вендорская тяжесть: лицензии на миллионы долларов, проприетарные конфигурации, консультанты. Термин «SOA» настолько дискредитировался, что аналитики хоронили его публично ещё в 2009 году (знаменитый пост Энн Томас Мэйнс «SOA is Dead; Long Live Services»).

Микросервисы: smart endpoints, dumb pipes

Четвёртая эпоха — микросервисы. В программной статье «Microservices» (2014) Джеймс Льюис и Мартин Фаулер сформулировали контрпринцип: «умные конечные точки и глупые трубы» (smart endpoints and dumb pipes). Логика — в сервисах, транспорт — тупой и дешёвый: HTTP/REST либо легковесный брокер сообщений (RabbitMQ, позже Kafka), который только доставляет байты и ничего не знает о бизнесе. Интеграционная сложность не исчезает — она возвращается в команды, владеющие сервисами, вместе с ответственностью и правом менять свой кусок независимо.

Важный нюанс, который часто упускают: маятник не вернулся в точку «point-to-point». Микросервисная эпоха унаследовала от шинной центральный транспорт (брокер/лог событий) — но отобрала у него право содержать логику. Современная интеграционная ткань — это тупая, но надёжная магистраль плюс умные, автономные участники. Именно эта формула ляжет в основу проектирования движка холдинга.

• 1990-еСпагетти и EAI.

  Point-to-point стыковки перерастают в N² «проводов»; в ответ — брокеры TIBCO, MQSeries, BizTalk и топология hub-and-spoke.

• ~2002Мандат Безоса.

  Amazon: только API-интерфейсы, всё externalizable, «кто не будет — будет уволен». Начало пути к AWS.

• 2003Enterprise Integration Patterns.

  Хоупи и Вульф публикуют каталог из 65 паттернов — до сих пор действующий язык интеграции.

• 2009«SOA is Dead».

  Энн Томас Мэйнс публично хоронит дискредитированный термин: логика утекла в шину, комитеты задушили скорость.

• 2011–13Kafka и «The Log».

  LinkedIn открывает Kafka; Джей Крепс публикует эссе о логе как унифицирующей абстракции данных компании.

• 2014«Microservices».

  Льюис и Фаулер: smart endpoints, dumb pipes. Сложность возвращается в команды вместе с правом меняться независимо.

• 2017Классификация событийности.

  Фаулер разводит event notification / event-carried state transfer / event sourcing; Kafka получает транзакции (KIP-98).

• 2019n8n и волна iPaaS.

  Open-core альтернатива Zapier: визуальный редактор поверх кода, self-hosted. «Интеграция для граждан» становится массовой.

• 2024–25MCP и A2A.

  Anthropic открывает Model Context Protocol («USB-C для AI»), Google — Agent2Agent; оба передаются Linux Foundation. Агент — полноправный интеграционный клиент.

6.2. Enterprise Integration Patterns: язык, на котором говорит интеграция

В 2003 году Грегор Хоупи и Бобби Вульф выпустили книгу «Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions» — каталог из 65 паттернов асинхронного обмена сообщениями. Прошло больше двадцати лет, сменились три поколения технологий, а книга остаётся действующим стандартом де-факто: сам Хоупи в докладе «Enterprise Integration Patterns 2» (YOW! 2017) показывал, что паттерны без изменений ложатся на Kafka, облачные очереди и serverless — потому что описывают не продукты, а фундаментальные решения задачи «как двум системам поговорить, не будучи доступными одновременно». Иконографика EIP (человечки, конвертики, воронки) встроена в документацию Apache Camel, Spring Integration, MuleSoft — это буквально общий язык отрасли.

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

Канал (Message Channel). Виртуальная труба, соединяющая отправителя и получателя. Ключевая развилка: канал «точка-точка» (point-to-point channel) — сообщение получит ровно один потребитель, так делают очереди задач; и канал «публикация-подписка» (publish-subscribe channel) — каждое сообщение получают все подписчики, так распространяются события. Выбор между ними — это выбор семантики: «поручение» или «оповещение». Путаница между ними — классическая ошибка: если событие «клиент оплатил» отправить в очередь точка-точка, то биллинг и email-рассылка будут вырывать сообщения друг у друга.

Сообщение (Message). Атом обмена: заголовки (метаданные — идентификатор, время, корреляция) плюс тело. EIP различает три вида по интенции: сообщение-команда (Command Message — «сделай»), сообщение-документ (Document Message — «вот данные») и сообщение-событие (Event Message — «произошло»). Различие кажется академичным, но именно оно определяет, кто несёт ответственность: команда подразумевает, что отправитель знает получателя и ждёт исполнения; событие — что отправителю всё равно, кто и как отреагирует. В безлюдном движке это различие станет границей между оркестрацией и хореографией (раздел 6.7).

Маршрутизатор (Message Router). Компонент, который решает, в какой канал направить сообщение: по содержимому (Content-Based Router), по списку получателей (Recipient List), с разделением на части (Splitter) и обратной сборкой (Aggregator). Aggregator — один из самых коварных паттернов: он обязан хранить состояние (какие части уже пришли), решать, когда «хватит» (по количеству, таймауту или условию), и что делать с опоздавшими.

Трансформатор (Message Translator). Преобразует формат одной системы в формат другой. Надстройка над ним — паттерн «канонической модели данных» (Canonical Data Model): вместо N×N попарных трансформаций каждая система переводится в общий промежуточный формат и обратно, что даёт 2N трансформаций. Здесь важна честная оговорка, которую делает и сам Хоупи: каноническая модель — самый «дорогой» паттерн каталога. Попытка согласовать единое «Понятие Клиента» на всю корпорацию порождает комитеты и полугодовые войны за поля. Практичный компромисс современности — канонические модели не всей корпорации, а отдельных доменов, плюс события как контракты (раздел 6.8): договариваемся о схеме события «СчётВыставлен», а не о вселенской модели счёта.

Отдельно стоит паттерн, который свяжет эту главу с темой агентов: Process Manager — компонент, который держит состояние многошагового процесса и решает, что делать дальше, на основании приходящих сообщений. В 2003 году это был BPEL-движок; в 2026-м на эту роль претендует LLM-агент. Хоупи в последние годы прямо развивает эту мысль: в статьях и докладах 2025 года (в том числе «Integration Patterns in the World of AI» и материалы на enterpriseintegrationpatterns.com) он показывает, что мультиагентные системы — это снова распределённые асинхронные системы, и им нужны те же Correlation Identifier, Return Address и Dead Letter Channel, только теперь между агентами.

6.3. Мандат Безоса: API как форма организации компании

Около 2002 года Джефф Безос разослал командам Amazon внутренний меморандум, ставший, вероятно, самым цитируемым организационным документом в истории software-индустрии. Сам текст никогда не публиковался — мир узнал о нём из «платформенного рант» Стива Йегги (Steve Yegge, «Google Platforms Rant», 2011), бывшего сотрудника Amazon, случайно опубликовавшего внутреннюю заметку Google на весь интернет. В пересказе Йегги мандат звучал примерно так:

1. Все команды отныне публикуют свои данные и функциональность только через сервисные интерфейсы (API).
2. Команды общаются друг с другом только через эти интерфейсы.
3. Никаких других форм межпроцессного взаимодействия: ни прямого чтения чужой базы данных, ни разделяемой памяти, ни «чёрных ходов». Единственное допустимое общение — вызовы сервисных интерфейсов по сети.
4. Неважно, какая технология используется.
5. Все интерфейсы, без исключений, должны проектироваться так, чтобы их можно было открыть внешнему миру (externalizable). Никаких «это только для внутренних».
6. Кто не будет это делать — будет уволен.

По свидетельству Йегги, завершался меморандум фразой в духе «Спасибо, хорошего дня!» — и Amazon действительно исполнил приказ, потратив годы на болезненную перестройку.

Механизм действия мандата глубже, чем «стандартизация интеграций». Во-первых, он сделал организационные границы техническими: команда, доступная только через API, — это команда, чью внутренность никто не знает и знать не должен. Это принудительная слабая связанность (loose coupling) на уровне оргструктуры — материализация закона Конвея в обратную сторону: спроектируй коммуникации, и архитектура подтянется. Во-вторых, правило №5 — «всё должно быть открываемо наружу» — заставило каждую команду проектировать интерфейсы как продукт: с документацией, версионированием, квотами, безопасностью, биллингом по использованию. Когда в 2006 году Amazon решил продавать свою инфраструктуру как сервис, значительная часть работы уже была сделана — так внутренний приказ стал одним из источников AWS, бизнеса с выручкой более $100 млрд в год. В-третьих, мандат создал измеримость: раз всё общение — вызовы API, значит, всё общение можно логировать, тарифицировать и анализировать.

Для холдинга из нескольких юрлиц мандат Безоса — почти буквальная инструкция. Управляющая компания и бизнес-активы должны взаимодействовать как Amazon-команды: каждый актив публикует свой «интерфейс» (финансовые события, операционные метрики, запросы на сервисы УК), и никто не лазает в чужую учётную систему напрямую. Это даёт три эффекта, критичных именно для холдинговой конструкции: (1) активы становятся отчуждаемыми — бизнес с чистым API-контуром можно продать или выделить, не выдирая его с мясом из общей ERP; (2) шаренные сервисы УК (бухгалтерия, юристы, казначейство) превращаются из «отдела» в платформу с внутренними тарифами; (3) появляется место, куда подключать агентов: агент — это просто ещё один клиент API, и если API нет, агенту некуда встать.

6.4. Событийная архитектура: три способа сказать «что-то произошло»

Слово «событийный» (event-driven) — одно из самых замусоренных в архитектурном лексиконе. Мартин Фаулер в статье «What do you mean by "Event-Driven"?» (2017) и кейноуте «The Many Meanings of Event-Driven Architecture» (GOTO Chicago 2017) разложил его на несколько принципиально разных паттернов. Эта классификация — обязательный инструмент: смешение паттернов в одном проекте порождает системы, которые никто не может отладить.

Event Notification: «случилось, подробности у меня»

Первый и самый лёгкий паттерн — событие-уведомление. Система-источник публикует минимальный факт: «Заказ 4711 оплачен» плюс идентификатор. Заинтересованные потребители, получив уведомление, сами приходят к источнику за деталями через API. Достоинство — минимальная связанность и маленькие сообщения; источник не обязан угадывать, какие данные понадобятся потребителям. Недостатки два: во-первых, всплеск обратных запросов (получили событие сто потребителей — сто запросов к API источника); во-вторых, то, что Фаулер называет утратой видимой картины поведения (нет места, где написано «что происходит после оплаты» — поведение размазано по подписчикам). Для аудита безлюдной системы это серьёзно: понадобится трассировка (correlation id) через весь каскад.

Event-Carried State Transfer: «случилось, вот всё, что нужно знать»

Второй паттерн — событие, переносящее состояние. В сообщение вкладывается полезная нагрузка: не только «заказ оплачен», но и сумма, состав, реквизиты клиента. Потребители складывают эти данные в собственные локальные копии и больше не дёргают источник. Это осознанная сделка: мы покупаем автономность и снятие нагрузки с источника ценой избыточности данных и — главное — итоговой согласованности (eventual consistency): в каждый момент копии могут слегка отставать. Для холдинга этот паттерн — рабочая лошадка: событие «СотрудникНанят» из HR-системы актива несёт всё, что нужно бухгалтерии УК, и бухгалтерский контур не зависит от доступности HR-системы.

Event Sourcing: события как единственная правда

Третий паттерн радикальнее: состояние системы вообще не хранится как «текущий снимок» — хранится полный журнал событий, а текущее состояние выводится проигрыванием журнала (с периодическими снапшотами для скорости). Канонический пример Фаулера — банковский счёт: остаток не «хранится», а вычисляется из истории проводок; бухгалтерский журнал и системы контроля версий (Git) — это event sourcing, проверенный веками и десятилетиями. Выгоды: полный аудиторский след «из коробки», возможность восстановить состояние на любой момент («time travel»), возможность задним числом извлечь аналитику, о которой не думали при записи. Цена: версионирование событий (журнал живёт годами, схемы меняются), сложность работы с внешними системами (replay не должен повторно списывать деньги) и непривычность для разработчиков. Практическое правило: event sourcing — не общесистемная догма, а инструмент для отдельных доменов, где аудит и история — суть бизнеса (деньги, права доступа, юридически значимые действия).

Четвёртый член семейства — CQRS (Command Query Responsibility Segregation), разделение моделей записи и чтения; Фаулер подчёркивает, что это отдельный паттерн, часто сочетаемый с event sourcing, но не обязательный.

Различать эти три паттерна — не педантизм. «Уведомление» связывает слабее всех, но создаёт скрытые каскады; «перенос состояния» дарит автономность, но плодит копии, которые надо уметь пересобирать; «event sourcing» даёт идеальный аудит, но требует зрелой инженерии. В одном движке будут жить все три — важно, чтобы выбор в каждой точке был осознанным и задокументированным.

6.5. Kafka и «Лог»: механика центральной нервной системы

В 2013 году Джей Крепс, тогда инженер LinkedIn, опубликовал эссе «The Log: What every software engineer should know about real-time data's unifying abstraction» — один из самых влиятельных технических текстов десятилетия (позже расширенный в книжку «I ♥ Logs», O'Reilly, 2014). Тезис Крепса: журнал (log) — упорядоченная, только дописываемая (append-only) последовательность записей — это универсальная абстракция, на которой уже стоят базы данных (WAL, журнал транзакций), репликация и распределённый консенсус. Если вынести лог из потрохов СУБД и сделать его самостоятельным сервисом, он становится единым местом обмена данными всей компании: каждая система пишет свои изменения в лог и читает чужие. Так LinkedIn решал проблему O(N²) интеграций между десятками хранилищ — и из этого решения родился Apache Kafka (открыт в 2011). Крепс и Confluent позже закрепили за этой ролью метафору «центральная нервная система предприятия» (central nervous system).

Механика: топики, партиции, офсеты

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

Топик (topic) — именованная категория событий («orders», «payments.completed»). Физически топик — это не одна очередь, а набор партиций (partitions): каждая партиция — отдельный append-only лог на диске. Событие с ключом (например, ID клиента) детерминированно попадает в одну партицию (хеш ключа по модулю числа партиций). Отсюда два фундаментальных следствия. Первое: порядок гарантируется только внутри партиции — все события одного клиента, попадая в одну партицию по ключу, будут прочитаны строго по порядку, но события разных клиентов между собой не упорядочены. Второе: партиция — единица параллелизма: сколько партиций, столько максимум потребителей могут читать топик одновременно в рамках одной группы.

Офсет (offset) — порядковый номер записи в партиции. Ключевое отличие Kafka от классических очередей (RabbitMQ, IBM MQ): брокер не удаляет сообщение после прочтения и вообще не следит, кто что прочитал. Каждый потребитель сам хранит свой офсет — «закладку» в логе. Сообщения удаляются только по политике хранения (retention): по времени (7 дней, год, бесконечно) или по размеру; отдельный режим — компактация (log compaction), при которой хранится последняя запись для каждого ключа, что превращает топик в постоянно актуальную таблицу-снимок. Из этого следует свойство, невозможное в классическом брокере: новый потребитель может подключиться и перечитать историю с нуля. Для безлюдного движка это означает: новый AI-агент или новый аналитический контур можно «обучить» на всей истории событий компании, просто отмотав офсет.

Consumer group — механизм масштабирования и разделения ролей. Потребители, объявившие один group.id, делят между собой партиции топика: каждая партиция читается ровно одним членом группы (семантика «очереди»). Разные группы читают независимо, каждая со своими офсетами (семантика «pub-sub»). Так один и тот же топик «payments.completed» одновременно обслуживает группу «бухгалтерия» (пишет проводки), группу «аналитика» (грузит в DWH) и группу «агент-казначей» (следит за кассовыми разрывами) — не мешая друг другу. При падении члена группы брокер переназначает его партиции живым (rebalancing) — отказоустойчивость потребителей встроена в протокол.

Надёжность хранения обеспечивается репликацией: каждая партиция имеет лидера и реплики на других брокерах (типично фактор 3), запись подтверждается после попадания на кворум in-sync-реплик (acks=all). С версии Kafka 4.0 (2025) устранена историческая зависимость от ZooKeeper — метаданными управляет встроенный консенсус KRaft, что заметно упростило эксплуатацию малых кластеров.

Почему это «нервная система», а не «очередь»

Сумма свойств — долговременное хранение, перечитываемость, порядок по ключу, дешёвый fan-out на любое число групп — сдвигает роль Kafka от «транспорта» к «источнику правды о происходящем». Данные в логе — это факты («заказ создан», «счёт оплачен»), а базы данных подключённых систем — производные представления этих фактов, которые можно пересобрать. Это разворот привычной картины мира, и он же — мостик к событийным паттернам Фаулера: лог делает event-carried state transfer и event sourcing инфраструктурно дешёвыми.

Оговорка про масштаб честности ради: Kafka спроектирован под LinkedIn-масштабы и требует эксплуатационной зрелости. Для компании, где событий тысячи в день, а не миллиарды, тот же архитектурный рисунок реализуется управляемыми сервисами (Confluent Cloud, Yandex Managed Kafka, Amazon MSK) или более лёгкими логами — Redpanda (совместимый с Kafka однобинарный движок на C++), NATS JetStream. Важно не «поставить Kafka», а сохранить свойства лога: упорядоченность, перечитываемость, множественных независимых читателей.

6.6. Гарантии доставки: почему безлюдность начинается с идемпотентности

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

Три семантики доставки

At-most-once («не более одного раза»): отправил и забыл. Быстро, дёшево, сообщения теряются при любом сбое. Допустимо только для телеметрии, где потеря единичного измерения безвредна.

At-least-once («хотя бы один раз»): отправитель повторяет отправку, пока не получит подтверждение (ack); потребитель подтверждает обработку. Сообщение не потеряется, но может прийти дважды: классический сценарий — потребитель обработал сообщение, но упал до отправки подтверждения; после рестарта брокер доставит сообщение снова. Это рабочий стандарт индустрии.

Exactly-once («ровно один раз») — святой Грааль, о котором важно понимать горькую правду: в общем случае между независимыми системами ровно-однократная доставка недостижима (это следствие задачи двух генералов). Достижима ровно-однократная обработка — и только внутри контура, контролирующего и транспорт, и состояние. Kafka с 2017 года (KIP-98) предлагает идемпотентного продюсера (брокер отбрасывает дубли повторных отправок по номерам последовательности) и транзакции (атомарная запись в несколько топиков + чтение с уровнем read_committed), что даёт exactly-once для цепочек «прочитал из Kafka — обработал — записал в Kafka» (Kafka Streams). Но как только на конце цепочки внешний мир — СУБД, платёжный API, отправка email, — гарантия заканчивается, и ответственность переходит на паттерны уровня приложения.

Идемпотентность: главная добродетель безлюдного потребителя

Раз дубли неизбежны, каждый потребитель обязан быть идемпотентным: повторная обработка того же сообщения не должна менять результат. Приёмы известны. Естественная идемпотентность: «установить статус = оплачен» можно повторять сколько угодно, в отличие от «увеличить баланс на 100». Ключ идемпотентности (idempotency key): каждое сообщение несёт уникальный ID; потребитель хранит таблицу обработанных ID (или уникальный индекс в БД) и молча пропускает повторы — именно так устроен API Stripe, где клиент передаёт заголовок Idempotency-Key и может безопасно ретраить платёжный запрос. Проектное правило: идемпотентность — не оптимизация, а часть контракта каждого обработчика; она должна проверяться тестом «подай то же событие дважды».

Проблема двойной записи и outbox-паттерн

Самая коварная ловушка — двойная запись (dual write). Сервис должен сделать два действия: записать заказ в свою БД и опубликовать событие «ЗаказСоздан» в брокер. Два независимых хранилища нельзя обновить атомарно: если сначала БД, потом брокер — падение между ними даст заказ без события (подписчики никогда не узнают); если наоборот — событие без заказа. Распределённые транзакции (2PC) между СУБД и брокером на практике недоступны или неприемлемо хрупки.

Решение — транзакционный outbox (transactional outbox, каталог microservices.io Криса Ричардсона). Событие записывается в специальную таблицу outbox в той же локальной транзакции, что и бизнес-данные, — атомарность даёт обычная СУБД. Отдельный процесс затем переносит записи из outbox в брокер: либо поллер (message relay), либо элегантнее — захват изменений (CDC, Change Data Capture): инструмент вроде Debezium читает журнал транзакций СУБД (WAL) и публикует вставки в outbox-таблицу как события в Kafka. Доставка получается at-least-once (реле может повториться) — что возвращает нас к идемпотентности потребителей. Связка «outbox + CDC + идемпотентный потребитель» — это фактический отраслевой стандарт надёжной публикации событий и обязательный элемент безлюдного контура.

Dead Letter Queue: приёмный покой для неперевариваемого

Последний рубеж — сообщения, которые не удаётся обработать: «ядовитые» (poison message — кривой формат, неожиданная схема) или бизнес-невозможные (оплата несуществующего заказа). Бесконечные ретраи заблокируют партицию; молчаливый отброс — потеря данных. Паттерн Dead Letter Channel (он же DLQ) из каталога EIP: после N неудачных попыток (обычно с экспоненциальными задержками через ретрай-топики — так устроена многоярусная схема ретраев в Uber) сообщение перекладывается в специальный канал с приложением диагностики. В человеческой компании DLQ разбирает дежурный инженер. В безлюдной — на DLQ обязаны стоять две вещи: алертинг с эскалацией на человека-владельца (единственное место, где человек в контуре обязателен) и, всё чаще, агент-разборщик: LLM-агент, который классифицирует причину, чинит исправимое (например, пересобирает событие по актуальной схеме) и суммирует остальное для человека. DLQ, на который никто не смотрит, — это то же потерянное сообщение, только с чистой совестью.

6.7. Оркестрация против хореографии: саги и компенсации

Бизнес-процесс редко умещается в одну систему. «Продать проект» в холдинге — это CRM (сделка), юридический контур (договор), финансы (счёт, поступление), ресурсный план (команда), учёт (выручка). Раз каждая система владеет своими данными и своей локальной транзакцией, встаёт вопрос: кто ведёт процесс целиком и что делать, если шаг №4 из шести провалился, когда шаги 1–3 уже совершены?

Сага: транзакция, разрезанная на части

Теоретический фундамент дала статья Гектора Гарсиа-Молины и Кеннета Салема «Sagas» (ACM SIGMOD, 1987) — задолго до микросервисов, для «долгоживущих транзакций» в СУБД. Идея: длинную транзакцию T разрезаем на последовательность локальных транзакций T1…Tn; для каждой Ti определяем компенсирующую транзакцию (compensating transaction) Ci, которая семантически отменяет её эффект. Если всё прошло — отлично; если упала Tk, исполняем компенсации Ck−1…C1 в обратном порядке. Ключевое слово — «семантически»: компенсация не «откат» (изменения Ti уже видны миру), а новое действие с обратным смыслом: не «стереть списание», а «сделать возврат»; не «удалить бронь», а «отменить бронь письмом с извинениями». Отсюда фундаментальное свойство саги: система проходит через промежуточные состояния, видимые снаружи, — атомарности и изоляции в смысле ACID нет, есть гарантия «либо всё доведено до конца, либо всё компенсировано». Некоторые действия некомпенсируемы (отправленное клиенту письмо не вернуть) — их ставят последним шагом (паттерн pivot transaction).

Хореография: процесс без дирижёра

Реализуют саги двумя способами. Хореография (choreography): центрального координатора нет, сервисы реагируют на события друг друга. CRM публикует «СделкаЗакрыта» → юридический сервис слышит и создаёт договор, публикует «ДоговорПодписан» → финансовый сервис выставляет счёт… Компенсации — тоже события («ПлатёжНеПрошёл» → все, кто успел что-то сделать, откатываются). Достоинства: минимальная связанность, нет единой точки отказа, новые участники подключаются без изменения существующих. Недостаток тот самый, о котором предупреждал Фаулер: процесс не существует нигде как артефакт. Чтобы ответить «где сейчас сделка №381 и почему она застряла», нужно реконструировать картину из логов пяти систем. С ростом числа шагов хореография превращается в то, что индустрия прозвала «pinball machine architecture»: событие мечется между сервисами, как шарик.

Оркестрация: центральный дирижёр

Оркестрация (orchestration): выделенный оркестратор хранит состояние экземпляра процесса и явно командует участниками — «юрслужба, создай договор», ждёт ответа, решает, что дальше, при сбое запускает компенсации. Процесс существует как читаемое определение (код или диаграмма), состояние каждого экземпляра наблюдаемо, тайм-ауты и эскалации — штатные конструкции. Плата: оркестратор — дополнительный компонент и потенциальное место для расползания чужой бизнес-логики (риск «ESB 2.0», если в оркестратор начинают писать правила доменов). Современный инструментарий зрел: Temporal (модель durable execution — код процесса на обычном языке, состояние переживает падения процессов и рестарты), Camunda/Zeebe (BPMN-диаграммы), AWS Step Functions, легковесные движки внутри фреймворков. Существенно, что оркестратор командует, но не содержит доменную логику участников — этим он отличается от ESB.

Практическая эвристика выбора устоялась в индустрии: хореография — для коротких цепочек из 2–3 шагов и для реакций, о которых источнику незачем знать (уведомления, проекции в аналитику); оркестрация — для длинных, денежных и юридически значимых процессов, где нужны наблюдаемость, тайм-ауты, повторные попытки и понятный ответ на вопрос «где застряло». Бернд Рюкер (сооснователь Camunda, книга «Practical Process Automation», O'Reilly, 2021) формулирует это как «events for facts, commands for intent»: факты распространяем событиями, намерения выражаем командами через оркестратор.

Для безлюдной компании у оркестрации есть ещё один, решающий аргумент: экземпляр процесса в оркестраторе — это готовый интерфейс наблюдения для агента и человека. «Покажи все зависшие онбординги клиентов» — запрос к оркестратору, а не форензика по логам. И наоборот: LLM-агент естественно встраивается как исполнитель шага («агент, подготовь драфт договора») или как обработчик исключений, тогда как сам каркас процесса остаётся детерминированным. Формула 2025–2026 годов, продвигаемая и Temporal, и Camunda: детерминированный оркестратор снаружи, стохастический интеллект внутри шагов — а не наоборот.

6.8. Схемы и контракты: schema registry, AsyncAPI, CloudEvents

В синхронном мире контракт между системами — это спецификация API (OpenAPI/Swagger). В событийном мире связь ещё коварнее: продюсер и консюмер не знают друг друга и не встречаются во времени. Событие, записанное сегодня, будет прочитано системой, которую напишут через год. Единственное, что их связывает, — схема события. Поэтому зрелость событийной архитектуры измеряется не размером кластера, а дисциплиной контрактов.

Schema Registry. Реестр схем — сервис, который хранит версии схем для каждого топика и, главное, проверяет совместимость при регистрации новой версии. Механика (на примере Confluent Schema Registry, есть аналоги Apicurio, Karapace): продюсер сериализует событие по схеме (Avro, Protobuf или JSON Schema), в сообщение вкладывается только идентификатор схемы, консюмер получает схему из реестра по ID. Реестр настраивается на режим совместимости: backward (новая схема читает старые данные — можно удалять поля и добавлять опциональные; консюмеров обновляют первыми), forward (старая схема читает новые данные — продюсеров обновляют первыми), full (оба направления) и их транзитивные варианты. Попытка зарегистрировать ломающую схему отклоняется на этапе CI — то есть инцидент «продюсер переименовал поле и уронил пять консюмеров» предотвращается механически, а не код-ревью. Netflix, к примеру, принудительно требует Avro-схему на продюсере (schema-at-producer) для всего конвейера Keystone.

CloudEvents — спецификация CNCF (одна из немногих «выпустившихся», graduated, январь 2024), стандартизирующая конверт события: обязательные атрибуты id, source, type, specversion, плюс time, subject, datacontenttype и расширения. CloudEvents не говорит ничего о полезной нагрузке — только о метаданных, зато определяет привязки (bindings) к HTTP, Kafka, AMQP, MQTT. Смысл: событие можно переносить между транспортами и маршрутизировать/фильтровать/трассировать generic-инфраструктурой, не понимающей домена. Поддержан Azure Event Grid, Google Eventarc, Knative, Argo Events. Для мультиюрлицевого движка CloudEvents — дешёвый способ сразу договориться о конверте: source различает юрлица и системы, type образует таксономию событий холдинга.

AsyncAPI — «OpenAPI для асинхронного мира»: машиночитаемое описание событийных интерфейсов — какие каналы есть, кто в них публикует, какие сообщения со схемами и какими транспортами. Версия 3.0 (декабрь 2023) развела операции send/receive и сделала описания переиспользуемыми. Из AsyncAPI-документов генерируются документация, код и — важное для безлюдности — каталог событий: инструменты вроде EventCatalog строят из описаний браузеруемый портал «какие события в компании существуют, кто владелец, какая схема». Для агентов такой каталог — то же, чем для людей была вики: способ узнать, на что можно подписаться.

Версионирование событий. Правила, выстраданные индустрией (подробно — у Грега Янга в «Versioning in an Event Sourced System»): совместимые изменения (добавить опциональное поле) — обычный путь; ломающие — только как новое событие/новая версия топика (order.v2) с периодом двойной публикации, либо через апкастеры (upcaster — трансформатор старой версии в новую при чтении). Запрещённый приём — «просто поменять смысл поля»: письменная семантика события — часть контракта, и для event sourcing со сроком хранения «годы» это вопрос выживания данных.

6.9. iPaaS и «интеграция для граждан»: Zapier, Make, n8n, Workato

Параллельно «тяжёлой» инженерной интеграции вырос целый рынок iPaaS (Integration Platform as a Service) — облачных платформ, где интеграция собирается визуально из готовых коннекторов. Gartner ведёт для них отдельный магический квадрант; условно рынок делится на «гражданский» полюс (Zapier, Make, IFTTT — интеграции строит маркетолог), корпоративный (Workato, Boomi, MuleSoft, Tray — строит интеграционная команда, но быстрее, чем кодом) и открытый/инженерный (n8n — визуальный редактор поверх кода, self-hosted).

Zapier — пионер и синоним жанра: более 8000 подключённых приложений, модель «триггер → действия» (zap). Сила — покрытие лонг-тейла SaaS; слабости для серьёзного контура: исполнение по расписанию/вебхуку без сложного ветвления (исторически), тарификация за задачу, делающая большие объёмы дорогими, и облачность без варианта self-hosted. Make (бывший Integromat) — визуальные сценарии с ветвлением и итераторами, дешевле на объёме. Workato — корпоративный полюс: recipes с управлением доступом, аудитом, SLA; типичный выбор, когда интеграции должны пройти комплаенс.

Отдельного разбора заслуживает n8n — из-за траектории, прямо релевантной теме книги. Проект родился в 2019 году в Берлине как open-core-альтернатива Zapier (лицензия fair-code: исходники открыты, self-hosted бесплатно). Два свойства сделали его любимцем инженеров: узел Code (полноценный JavaScript/Python внутри workflow — визуальность не упирается в потолок) и self-hosting (данные не покидают контур — критично для персональных и финансовых данных нескольких юрлиц). А в 2023–2025 n8n совершил «AI-нативный поворот»: узлы LLM, память, векторные хранилища и агентные конструкции (AI Agent node с инструментами) стали первоклассными элементами workflow, и платформа переопределила себя из «автоматизации» в «оркестрацию AI». Рынок оценил: в октябре 2025 n8n поднял раунд C на $180 млн при оценке $2,5 млрд (лид — Accel), годом ранее оценка была порядка $350 млн — рост на порядок за год отражает спрос именно на связку «интеграции + агенты». Для практиков n8n стал ещё и «глиной» для агентных бэк-офисов: тысячи публичных шаблонов агентных автоматизаций.

Когда no-code интеграция — правильный выбор, а когда — техдолг

Честная рамка выбора выглядит так. iPaaS — правильный выбор, когда: связка периферийная (уведомление в мессенджер, синк в таблицу, обогащение лида), объёмы умеренные, цена ошибки — неудобство, а не убыток; когда нужен эксперимент за час вместо спринта; когда коннектор к экзотическому SaaS уже написан за вас (это главный актив iPaaS — оплаченный чужой труд по обёртыванию тысяч API).

iPaaS становится техдолгом, когда через него начинают течь основные бизнес-процессы. Признаки деградации известны каждому, кто видел «Zapier-компанию» изнутри: сотни сценариев без версионирования и тестов, логика размазана и нигде не описана, при сбое коннектора процессы молча останавливаются (у «гражданских» сценариев нет DLQ и алертинга), знание о том, почему сценарий устроен так, живёт в голове уволившегося оунера. Это point-to-point спагетти из раздела 6.1, только в красивом интерфейсе — маятник истории, пробеганный за полтора года. Инженерная рамка разграничения: всё, что касается денег, обязательств и данных клиентов, идёт через событийную магистраль с контрактами (разделы 6.5–6.8); iPaaS живёт на периферии как «капилляры» — и даже там сценарии подлежат минимальной дисциплине (экспорт в git, владелец, алерт на сбой). У n8n здесь преимущество: workflow — это JSON в git, self-hosted инстанс встраивается в общий мониторинг, а вебхук-узлы позволяют подключать n8n-сценарии как потребителей событийной шины, а не как параллельную вселенную.

6.10. Webhooks, polling и API-first экономика

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

Polling против webhooks

Поллинг (polling) — потребитель периодически спрашивает: «есть что новое?». Просто, надёжно (инициатива у потребителя, ничего не теряется — можно перечитать), но неэффективно: 98–99% запросов возвращают «ничего нового», а свежесть данных ограничена интервалом опроса. Webhook — обратный вызов: вы регистрируете у провайдера URL, и он сам делает HTTP POST при событии. Задержка — секунды, накладные расходы — нулевые, но инициатива теперь у чужой системы, и это порождает список обязательных инженерных мер, который стоит знать наизусть, потому что каждая пропущенная — источник молчаливых потерь. Приёмник обязан: (1) отвечать 2xx мгновенно, складывая полезную нагрузку во внутреннюю очередь, а не обрабатывая синхронно (иначе таймауты и повторные доставки); (2) проверять подпись (обычно HMAC-подпись тела с общим секретом — так делают Stripe и GitHub), иначе любой в интернете сможет «прислать вам платёж»; (3) быть идемпотентным — все серьёзные провайдеры доставляют вебхуки at-least-once с ретраями; (4) уметь восстанавливаться после простоя — вебхуки, отправленные, пока ваш приёмник лежал, у многих провайдеров пропадают после исчерпания ретраев, поэтому зрелый рисунок — «webhook как звонок + периодический reconciliation-поллинг как сверка». Заметно движение к стандартизации: спецификация Standard Webhooks (2023, при участии Svix) кодифицирует подписи, заголовки и ретраи; в 2025–2026 набирает вес и передача событий провайдерами напрямую в очереди клиента (Stripe → Amazon EventBridge и т.п.), минуя HTTP-приёмники.

API-first экономика: Stripe и Twilio как образцы

Сам факт, что стыковка с банком или телефонией — это «зарегистрировал вебхук и сделал три вызова», — заслуга API-first компаний, прежде всего Stripe (платежи) и Twilio (коммуникации). Их продукт — сам API, поэтому в дизайн интерфейсов вложено то, что обычные компании вкладывают в витрины. Этот дизайн стоит изучать как эталон, проектируя внутренние API холдинга: предсказуемые REST-ресурсы и коды ошибок с человекочитаемым объяснением и ссылкой на документацию; ключи идемпотентности на всех мутирующих операциях; версионирование, не ломающее клиентов (Stripe фиксирует версию API за аккаунтом и десятилетиями поддерживает старые); тестовый режим как первоклассный гражданин (test mode с теми же интерфейсами — прообраз «песочницы» для агентов); события обо всём происходящем (у Stripe любое изменение объекта порождает событие в едином формате). Экономический смысл API-first экономики для нашей темы: каждая функция бэк-офиса, которую раньше исполнял отдел, сегодня доступна как API-сервис — платежи, КЭП и документооборот, проверки контрагентов, логистика. Безлюдный движок — это в значительной мере композиция чужих API поверх собственной событийной магистрали; собственной разработки заслуживает только то, что составляет уникальность бизнеса.

6.11. Интеграционный слой как место для агентов: MCP, function calling, A2A

До 2023 года у интеграционного слоя было два типа клиентов: программы (детерминированный код) и люди (через UI). Появился третий — AI-агент: клиент, который читает документацию, сам решает, какой инструмент вызвать, и делает это на естественно-языковом рассуждении. Для интеграционной ткани это тектонический сдвиг, сопоставимый с мандатом Безоса: всё, что было «API для разработчиков», становится «инструментами для агентов».

Function calling: элементарный механизм

База — вызов функций (function calling, у Anthropic — tool use), появившийся в API OpenAI в июне 2023-го. Механика: модели вместе с запросом передаётся список инструментов — JSON Schema описаний функций (имя, назначение, параметры). Модель не исполняет функцию — она возвращает структурированное намерение: «вызови create_invoice с amount=120000, client_id=381». Приложение исполняет вызов, возвращает результат в контекст, модель продолжает рассуждение — цикл повторяется до финального ответа. Два следствия для проектировщика. Первое: качество работы агента прямо зависит от качества описаний инструментов — документация API впервые стала исполняемым кодом (её читает не человек, а модель, и от формулировки зависит поведение). Второе: детерминизм гарантирует только слой исполнения — сама модель может вызвать не тот инструмент или не с теми параметрами, поэтому права инструментов и валидация параметров — граница безопасности, а не формальность.

MCP: «USB-C для AI»

Function calling у каждого вендора был свой, и каждая связка «модель × инструмент» писалась заново — знакомая по разделу 6.1 картина M×N. Ответом стал Model Context Protocol (MCP), открытый Anthropic в ноябре 2024 года, — стандартный протокол подключения источников контекста и инструментов к любой модели, за что немедленно получил прозвище «USB-C для AI». Механика: MCP-сервер — лёгкая обёртка над системой (CRM, БД, файлы, браузер), публикующая по стандартному протоколу (JSON-RPC поверх stdio или HTTP) три вида возможностей: инструменты (tools — действия), ресурсы (resources — данные для чтения) и подсказки (prompts — шаблоны). MCP-клиент (Claude, IDE, любой агентный рантайм) подключается к любому набору серверов, и M×N превращается в M+N. Переломным стал 2025 год: в марте протокол приняла OpenAI, затем Google DeepMind и Microsoft; счёт публичных MCP-серверов пошёл на тысячи, а в декабре 2025 Linux Foundation объявила о создании Agentic AI Foundation (AAIF), куда Anthropic передала MCP как якорный проект — протокол стал вендор-нейтральным стандартом де-факто. Практический смысл для холдинга: MCP-сервер — это новый «разъём», который должен быть у каждой внутренней системы, наравне с REST API и потоком событий. Написать MCP-обёртку над существующим API — дни работы; после этого система доступна всем агентам компании без индивидуальных интеграций.

A2A и протокольный стек агентной экономики

MCP соединяет агента с инструментами; следующий уровень — агенты, говорящие друг с другом. Протокол Agent2Agent (A2A) представлен Google в апреле 2025 года с поддержкой более 50 партнёров и в июне 2025 передан Linux Foundation. Механика: каждый агент публикует «визитку» (Agent Card — JSON-описание возможностей), взаимодействие строится вокруг задач (task) с жизненным циклом — создана, исполняется, требует уточнения, завершена, — что удобно для долгих асинхронных поручений между агентами разных организаций. Рядом формируются смежные протоколы: ACP, AGNTCY, платёжные расширения (AP2, x402) для расчётов между агентами (стек 2025–2026 годов ещё не устоялся; сводные обзоры сходятся, что пара MCP+A2A — наиболее вероятное ядро, остальное — «(непроверено)» в части выживаемости). Читатель заметит рифму: Agent Card — это WSDL, A2A-задача — это durable-процесс, реестры агентов — это UDDI из эпохи SOA. Урок истории из раздела 6.1 применим буквально: выживут протоколы, которые останутся тупыми трубами, и умрут те, что попытаются стандартизировать семантику бизнеса.

Важно удержать трезвую рамку: агент не отменяет интеграционную ткань, а опирается на неё. Агент, «который сам ходит по UI», — это хрупкий скрейпинг; агент поверх чистых API, событийного лога (как источника фактов о происходящем) и оркестратора (как каркаса длинных процессов) — это надёжный работник. Формула безлюдного движка: события — сенсорика агентов, MCP — их моторика, оркестратор — их дисциплина.

6.12. Реальные архитектуры: Netflix и Uber против компании на 50 человек

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

Netflix: конвейер событий как продукт

Netflix пропускает через событийный конвейер Keystone поток взаимодействий сотен миллионов пользователей: уже в 2016 году — 36 Kafka-кластеров и более 700 млрд сообщений в день, к 2022-му — свыше 2 трлн событий в день; в задачах мониторинга живых трансляций пики достигали 38 млн событий в секунду (2025). Архитектурные решения, интересные не масштабом, а принципом: двухуровневая топология (fronting-кластеры принимают события от продюсеров, отдельные кластеры обслуживают потребителей — приём отвязан от фан-аута, и никакой прожорливый потребитель не уронит приём); обязательная схема на продюсере (Avro + внутренний schema registry — событие без схемы не принимается); «умные клиенты», скрывающие от приложений физическую топологию (приложение пишет в логическую точку, маршрутизацию решает платформа).

Uber: дисциплина надёжности

Kafka в Uber — трансконтинентальная система: триллионы сообщений и петабайты в день (данные 2021 года), десятки кластеров, ~200 тысяч партиций, рост пропускной способности с 1 до 12 млн сообщений в секунду за пять лет. Переносимые принципы: собственный слой репликации между кластерами (uReplicator); Consumer Proxy/uForwarder — прокси, который сам читает партиции и push-ем раздаёт сообщения тысяче сервисов, снимая с продуктовых команд бремя грамотного консюмера; многоярусные ретраи с DLQ как штатная топология каждого потока; и Chaperone — сквозной аудит потока, сверяющий счётчики сообщений на каждом ярусе конвейера (20 000+ топиков в десятиминутных окнах), то есть автоматический ответ на вопрос «не потеряли ли мы что-нибудь». Заметьте: у Uber и Netflix значительная часть инженерии потрачена не на «скорость», а на гарантии и наблюдаемость — на то, что в безлюдной компании критично при любом масштабе.

Компания на 50 человек: минимально достаточная шина

Теперь честный переход к масштабу малой компании и холдинга Алексея. Копировать Netflix — ошибка калибровки: у компании на 50 человек нет ни миллиона событий в секунду, ни платформенной команды. Но у неё есть та же логическая задача: несколько систем и несколько (в будущем — десятки) агентов должны согласованно знать, что происходит. Минимально достаточная интеграционная ткань холдинга из нескольких юрлиц выглядит так (см. рис. 6.1).

Транспорт: один управляемый лог событий (управляемая Kafka / Redpanda / NATS JetStream — по вкусу и бюджету; выбор бренда второстепенен относительно свойств: порядок по ключу, retention в годы, перечитываемость). Один кластер на весь холдинг, юрлица разделяются неймспейсами топиков и ACL — «мультиарендная» шина вместо шины на юрлицо.

Контракты: конверт CloudEvents; схемы в реестре с backward-совместимостью; каталог событий, сгенерированный из AsyncAPI. Таксономия топиков по доменам: finance.*, sales.*, hr.*, legal.* — с явным владельцем каждого домена.

Надёжность: outbox/CDC на каждом продюсере, идемпотентность на каждом потребителе, DLQ с алертом на каждом топике, сквозная сверка produced/consumed раз в сутки (мини-Chaperone — это один скрипт или один агент).

Процессы: один оркестратор (Temporal или Camunda) для денежных и межюрлицевых саг. Периферия: self-hosted n8n для длинного хвоста связок и агентных пилотов, подключённый к шине как обычный клиент. Агентный слой: MCP-серверы над ключевыми системами, агенты подписаны на события и действуют через инструменты с лимитами.

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

Источники и куда копать глубже