Проектирование интеграций
Как аналитик проектирует интеграции систем — топологии и виды интеграций, синхронное и асинхронное взаимодействие, оркестрация и хореография, брокеры сообщений и чек-лист проектирования.
17 вопросов
JuniorТеорияОчень частоКакие виды интеграций между системами вы знаете?
Какие виды интеграций между системами вы знаете?
По механизму основные виды: API (REST, SOAP, gRPC, GraphQL) для вызовов запрос/ответ; брокеры и очереди сообщений (Kafka, RabbitMQ, IBM MQ) для асинхронного обмена; ESB для централизованной маршрутизации; файловый обмен по расписанию; и прямые подключения к базе.
Типичные ошибки
- ✗Называть только API, забывая брокеры, ESB, файлы или DB-connect
- ✗Считать брокер сообщений синхронным запрос/ответ
- ✗Путать ESB с одним API-шлюзом
Уточняющие вопросы
- →Когда файловый обмен предпочтительнее API?
- →Чем прямой DB-connect рискован как способ интеграции?
MiddleТеорияОчень частоЗачем в интеграции применяют брокеры сообщений?
Зачем в интеграции применяют брокеры сообщений?
Брокер сообщений развязывает производителя и потребителя: производитель отдаёт сообщение брокеру и идёт дальше, потребитель читает в своём темпе. Это даёт асинхронное взаимодействие, гарантированную доставку (брокер сохраняет и повторяет до подтверждения) и сглаживание узких горлышек в длинных интеграционных цепочках, ведь очередь поглощает всплески нагрузки. На масштабе партиции дают параллельное чтение топика.
Типичные ошибки
- ✗Думать, что брокер ускоряет синхронные вызовы, а не развязывает
- ✗Забывать, что сохранение + повторы — это и есть гарантия доставки
- ✗Не знать, что партиции дают параллельное потребление
Уточняющие вопросы
- →За счёт чего брокер достигает гарантированной доставки?
- →Как партиции помогают потреблять топик параллельно?
MiddleТеорияОчень частоЧем синхронное взаимодействие отличается от асинхронного и что такое оркестрация против хореографии?
Чем синхронное взаимодействие отличается от асинхронного и что такое оркестрация против хореографии?
При синхронном взаимодействии вызывающий ждёт ответа и связан с доступностью вызываемого; при асинхронном — отправляет сообщение и продолжает, развязанный очередью. Оркестрация использует центральный координатор, ведущий шаги; хореография — реакции систем на события.
Типичные ошибки
- ✗Менять местами определения синхронного и асинхронного
- ✗Путать оркестрацию (центральный координатор) с хореографией (реакции на события)
- ✗Считать, что асинхрон убирает нужду в гарантиях доставки
Уточняющие вопросы
- →Когда вы выберете оркестрацию, а не хореографию?
- →Какой минус у синхронного вызова при недоступности получателя?
JuniorТеорияЧастоКакие топологии интеграции систем вы знаете?
Какие топологии интеграции систем вы знаете?
По форме связей: точка-точка — каждая пара соединяется напрямую, поначалу просто, но число связей взрывается с ростом систем; звезда/шина (hub-and-spoke, ESB) — все системы идут через один центральный узел; и смешанная. Также делят на вертикальные и горизонтальные.
Типичные ошибки
- ✗Менять местами определения точка-точка и hub-and-spoke
- ✗Утверждать, что точка-точка масштабируется без роста связей
- ✗Путать ось вертикальные/горизонтальные с ориентацией диаграммы
Уточняющие вопросы
- →Почему число связей в точка-точка растёт быстрее, чем в звезде?
- →Какую роль играет ESB в топологии «шина»?
MiddleДизайнЧастоВы проектируете три интеграции для розничной платформы. Первая: клиент оформляет заказ и должен сразу получить номер заказа. Вторая: изменение цены должно дойти до 200 бэк-офисов магазинов, часть которых в любой момент офлайн. Третья: бухгалтерии каждую ночь нужен полный отчёт о продажах. Для каждого случая выберите между синхронным API и асинхронным брокером сообщений и обоснуйте выбор через задержку, связанность и требования доставки.
Вы проектируете три интеграции для розничной платформы. Первая: клиент оформляет заказ и должен сразу получить номер заказа. Вторая: изменение цены должно дойти до 200 бэк-офисов магазинов, часть которых в любой момент офлайн. Третья: бухгалтерии каждую ночь нужен полный отчёт о продажах. Для каждого случая выберите между синхронным API и асинхронным брокером сообщений и обоснуйте выбор через задержку, связанность и требования доставки.
Оформление заказа требует немедленного ответа — синхронный API, возвращающий номер заказа. Обновление цены веером идёт на 200 офлайн-терпимых магазинов без ответа — брокер сообщений. Ночной отчёт массовый и по времени — пакетная выгрузка по расписанию.
Типичные ошибки
- ✗Брать брокер там, где нужен немедленный синхронный ответ
- ✗Веерить синхронным вызовом, что падает при одном офлайн-узле
- ✗Стримить массовый ночной отчёт вместо пакета
Уточняющие вопросы
- →Почему брокер подходит для веера на офлайн-потребителей?
- →Что подтверждает, что заказ клиента действительно прошёл?
MiddleДизайнЧастоНужно интегрировать две системы, но каждая моделирует клиента по-своему. Одна хранит единое поле полного имени, код статуса и страну двухбуквенным кодом; другая делит имя и фамилию, использует текстовую метку статуса и хранит полное название страны. Постройте маппинг данных между ними и опишите, как вы его задокументируете, чтобы разработчики и тестировщики могли построить и проверить интеграцию.
Нужно интегрировать две системы, но каждая моделирует клиента по-своему. Одна хранит единое поле полного имени, код статуса и страну двухбуквенным кодом; другая делит имя и фамилию, использует текстовую метку статуса и хранит полное название страны. Постройте маппинг данных между ними и опишите, как вы его задокументируете, чтобы разработчики и тестировщики могли построить и проверить интеграцию.
Постройте таблицу поле-в-поле: источник, приёмник, правило преобразования. Разбейте полное имя на имя и фамилию, переведите код статуса через справочник, разверните код страны через справочную таблицу. Задокументируйте умолчания и обработку неверных значений — это контракт.
Типичные ошибки
- ✗Считать, что поля сходятся без правил преобразования
- ✗Копировать код как есть вместо перевода по справочнику
- ✗Опускать умолчания и обработку пропусков и неверных значений
Уточняющие вопросы
- →Как смаппить метку статуса без подходящего кода?
- →Где держать справочник стран и кто им владеет?
MiddleТеорияЧастоКакие ошибки обязана описывать спецификация интеграции и чем техническая ошибка отличается от бизнес-ошибки?
Какие ошибки обязана описывать спецификация интеграции и чем техническая ошибка отличается от бизнес-ошибки?
Спецификация обязана покрыть технические ошибки (timeout, 5xx) и бизнес-ошибки (недостаточно средств). Техническая ошибка — сбой транспорта, обычно повторяемый; бизнес-ошибка — валидный отказ, который повторять нельзя. Каждой нужен код, сообщение и действие.
Типичные ошибки
- ✗Повторять бизнес-ошибку, будто она временная
- ✗Описывать лишь счастливый путь без каталога ошибок
- ✗Менять местами определения технической и бизнес-ошибки
Уточняющие вопросы
- →Какой диапазон HTTP-статусов подходит отказу по бизнес-правилу?
- →Почему бизнес-ошибку нельзя повторять автоматически?
MiddleТеорияЧастоЧто такое ESB (enterprise service bus) и чем она отличается от обычной очереди сообщений?
Что такое ESB (enterprise service bus) и чем она отличается от обычной очереди сообщений?
ESB — это центральный узел, добавляющий маршрутизацию, преобразование сообщений, адаптацию протоколов и оркестрацию. Очередь сообщений лишь переносит сообщения между производителем и потребителем, не маршрутизируя их по содержимому. Очередь — транспорт, ESB — платформа поверх.
Типичные ошибки
- ✗Считать ESB и очередь взаимозаменяемыми
- ✗Думать, что обычная очередь маршрутизирует по содержимому
- ✗Упускать, что логика ESB централизована в шине
Уточняющие вопросы
- →Какой риск создаёт централизация логики в ESB?
- →Когда обычной очереди достаточно без полноценной ESB?
MiddleДизайнЧастоВаша система синхронно вызывает внешнего платёжного провайдера, но тот иногда не отвечает в пределах timeout. Деньги могли списаться, а могли и нет. В спецификации интеграции опишите, что делает вызывающий при timeout — повтор, компенсацию или отказ — и как вы удержите результат корректным, чтобы клиента не списали дважды и он не остался в неизвестном состоянии.
Ваша система синхронно вызывает внешнего платёжного провайдера, но тот иногда не отвечает в пределах timeout. Деньги могли списаться, а могли и нет. В спецификации интеграции опишите, что делает вызывающий при timeout — повтор, компенсацию или отказ — и как вы удержите результат корректным, чтобы клиента не списали дважды и он не остался в неизвестном состоянии.
Timeout значит, что результат неизвестен, а не провален — нельзя слепо повторять списание. Сделайте запрос идемпотентным с ключом клиента, чтобы безопасный повтор попал в то же списание. Если исход неизвестен, запросите статус или пометьте платёж pending для сверки позже.
Типичные ошибки
- ✗Повторять списание без ключа идемпотентности после timeout
- ✗Считать, что timeout значит гарантированный провал операции
- ✗Оставлять платёж в неизвестном состоянии без сверки
Уточняющие вопросы
- →Как ключ идемпотентности делает повтор здесь безопасным?
- →Что даёт состояние pending, чего не даёт жёсткий отказ?
SeniorДизайнЧастоПроектируя асинхронный обмен между системами, как вы продумаете обработку ошибок, гарантию доставки и идемпотентность, чтобы сообщение не потерялось и не применилось дважды?
Проектируя асинхронный обмен между системами, как вы продумаете обработку ошибок, гарантию доставки и идемпотентность, чтобы сообщение не потерялось и не применилось дважды?
Решите, где ошибки обнаруживаются и как обрабатываются: обнаружившая система повторяет и самовосстанавливается и/или оповещает людей. Гарантируйте доставку сохранением, подтверждениями и повторами с dead-letter. Сделайте потребителей идемпотентными через уникальный id.
Типичные ошибки
- ✗Считать доставку гарантированной без сохранения, подтверждений и повторов
- ✗Пропускать идемпотентность, так что повторённое сообщение применяется дважды
- ✗Не оставлять журналирования/мониторинга, делая сбои невидимыми
Уточняющие вопросы
- →Как уникальный id сообщения обеспечивает идемпотентность потребителя?
- →Что делать с «ядовитым» сообщением, которое стабильно падает?
JuniorТеорияИногдаЧто такое файловый обмен как вид интеграции, когда его всё ещё применяют и какие у него минусы?
Что такое файловый обмен как вид интеграции, когда его всё ещё применяют и какие у него минусы?
Файловый обмен — это когда одна система пишет файл (CSV, XML) в общую папку или на FTP, а другая по расписанию опрашивает и читает его. Он всё ещё подходит для массовых ночных загрузок и легаси-систем без API. Минусы: высокая задержка, нет реального времени, хрупкий разбор.
Типичные ошибки
- ✗Путать файловый обмен с вызовом API в реальном времени
- ✗Утверждать, что у него нет рисков доставки и разбора
- ✗Говорить, что файловый обмен не применяют в современных системах
Уточняющие вопросы
- →Как сделать файловую загрузку возобновляемой после сбоя?
- →Когда файловый обмен предпочтительнее API?
JuniorТеорияИногдаДолжен ли синхронный вызов всегда возвращать ответ и синхронен ли вызов хранимой процедуры или он асинхронен?
Должен ли синхронный вызов всегда возвращать ответ и синхронен ли вызов хранимой процедуры или он асинхронен?
Да — синхронный вызов блокирует вызывающего до возврата ответа, пусть и голого подтверждения, поэтому он связан с доступностью вызываемого. Асинхронный — это отправить и продолжить через очередь. Вызов хранимой процедуры синхронен: вызывающий ждёт её результат.
Типичные ошибки
- ✗Думать, что синхронный — это отправил и забыл без ответа
- ✗Называть вызов хранимой процедуры асинхронным
- ✗Считать, что пустое подтверждение — это не ответ
Уточняющие вопросы
- →Как очередь превращает вызов в асинхронный обмен?
- →Почему синхронный вызывающий зависит от доступности вызываемого?
MiddleТеорияИногдаЧем ESB (enterprise service bus) отличается от инструмента ETL (extract-transform-load) и когда выбирают каждый?
Чем ESB (enterprise service bus) отличается от инструмента ETL (extract-transform-load) и когда выбирают каждый?
ESB перемещает сообщения почти в реальном времени, добавляя маршрутизацию и преобразование. Инструмент ETL по расписанию извлекает пакет, преобразует и загружает его в хранилище — пропускная способность важнее задержки. ESB — для живой интеграции; ETL — для массовых переносов.
Типичные ошибки
- ✗Менять местами, какой инструмент реального времени, а какой пакетный
- ✗Думать, что ETL — это транспорт реального времени с низкой задержкой
- ✗Считать, что преобразовывать данные умеет лишь один из них
Уточняющие вопросы
- →Что подходит для ночной загрузки продаж в склад данных?
- →Могут ли ESB и ETL сосуществовать в одном ландшафте? Как?
SeniorДизайнИногдаВам поручили спроектировать интеграцию между двумя банковскими системами: одна — мастер-источник данных о клиентах, вторая должна получать обновления. Опишите, какие вопросы вы проработаете и в каком порядке, чтобы выдать полноценный проект интеграции.
Вам поручили спроектировать интеграцию между двумя банковскими системами: одна — мастер-источник данных о клиентах, вторая должна получать обновления. Опишите, какие вопросы вы проработаете и в каком порядке, чтобы выдать полноценный проект интеграции.
Начните с бизнес-потребности и use case, затем назовите системы и инициатора. Постройте регламент обмена (источник, приёмник, триггер, данные), соберите объём и частоту, специфицируйте мастер-источник и маппинг, затем детализируйте ошибки, гарантии доставки и мониторинг.
Типичные ошибки
- ✗Выбирать технологию до понимания бизнес-потребности и данных
- ✗Пропускать количественные показатели (частота, объём, рост)
- ✗Откладывать обработку ошибок, гарантии доставки и мониторинг на потом как мелочь
Уточняющие вопросы
- →Что должна содержать таблица регламента обмена?
- →Зачем фиксировать ожидаемый объём и частоту до выбора технологии?
SeniorДизайнИногдаПартнёр будет интегрироваться с вашей системой, но передаёт лишь коллекцию Postman с примерами запросов — без письменной документации, схемы и каталога ошибок. Вам нужно превратить это в полноценный контракт интеграции, по которому смогут работать разработчики. Опишите, как вы восстанавливаете и документируете контракт из коллекции и какие пробелы обязаны закрыть, спросив партнёра, а не додумывая.
Партнёр будет интегрироваться с вашей системой, но передаёт лишь коллекцию Postman с примерами запросов — без письменной документации, схемы и каталога ошибок. Вам нужно превратить это в полноценный контракт интеграции, по которому смогут работать разработчики. Опишите, как вы восстанавливаете и документируете контракт из коллекции и какие пробелы обязаны закрыть, спросив партнёра, а не додумывая.
Считайте коллекцию примерами, а не спецификацией. Извлеките эндпоинты, методы, авторизацию и поля, затем выведите типы и форматы как неподтверждённые. Спросите у партнёра, чего образцы не покажут: смысл полей, каталог ошибок, лимиты, версионирование. Подтвердите до разработки.
Типичные ошибки
- ✗Считать примеры запросов полной финальной спецификацией
- ✗Выводить каталог ошибок и лимиты вместо вопроса партнёру
- ✗Считать поле, встреченное раз, всегда обязательным
Уточняющие вопросы
- →Что примеры никогда не раскроют об ограничениях поля?
- →Зачем сперва подтверждать восстановленный контракт с партнёром?
SeniorДизайнИногдаДве системы обмениваются обновлениями по клиентам, но ключуют одного человека разными идентификаторами — CRM своим числовым id клиента, биллинг — номером договора, и ни одна не знает ключ другой. Единого универсального id нет. Спроектируйте, как интеграция сопоставляет две идентичности, чтобы обновление из одной системы надёжно попадало в нужную запись в другой, и опишите, как вы обрабатываете клиента, которого сопоставить не удалось.
Две системы обмениваются обновлениями по клиентам, но ключуют одного человека разными идентификаторами — CRM своим числовым id клиента, биллинг — номером договора, и ни одна не знает ключ другой. Единого универсального id нет. Спроектируйте, как интеграция сопоставляет две идентичности, чтобы обновление из одной системы надёжно попадало в нужную запись в другой, и опишите, как вы обрабатываете клиента, которого сопоставить не удалось.
Постройте таблицу перекрёстных ссылок, связывающую id каждой стороны с id другой. Заполните её сопоставлением по стабильным атрибутам (ИНН), затем держите её главной. Нечёткие совпадения оценивайте баллами и проверяйте вручную; несопоставленного клиента изолируют, не сливают силой.
Типичные ошибки
- ✗Считать, что два разных ключа держат одно значение
- ✗Авто-сливать нечёткие совпадения без очереди проверки
- ✗Удалять или силой сливать несопоставленного клиента
Уточняющие вопросы
- →Какие атрибуты дают самые надёжные ключи сопоставления?
- →Как поздние сообщения избегают повторного сопоставления с нуля?
SeniorДебаггингРедкоВеб-сервис на корпоративной шине добавил два новых обязательных поля. Что сломается и что придётся изменить в интеграции?
Веб-сервис на корпоративной шине добавил два новых обязательных поля. Что сломается и что придётся изменить в интеграции?
Теперь каждое сообщение падает у приёмника: сервис отклоняет запросы без двух обязательных полей, хотя источники не менялись. Исправьте, обновив маппинг на шине для поставки полей, подняв версию контракта и обновив потребителей и тесты. Выкатывайте с обратной совместимостью.
Открыть задачу →Типичные ошибки
- ✗Считать, что шина сама заполняет пропущенные обязательные поля
- ✗Менять только источник, пропуская маппинг на шине
- ✗Выкатывать без подъёма версии и обратной совместимости
Уточняющие вопросы
- →Откуда шина может взять значения новых полей?
- →Как не потерять сообщения в пути во время изменения?
