В прошлой части мы разобрались, что такое интеграция и с чем её едят.
И казалось бы всё, тимлид, давай задачку, ща спроектируем
Но тут важно понимать одну вещь:
Интеграции бывают разные.
И если выбрать не ту модель, могут быть проблемы.
Начнем с того, что мы их можем разделить по двум направлениям:
1. С кем мы интегрируемся.
2. Как мы это делаем.
1. С кем: внутренние и внешние
🏠Внутренняя интеграция (Internal)
Когда мы связываем наш сервис с другим сервисом внутри компании.
Пример:
Сервис «Оформление заказа» стучится в сервис «Склад», чтобы проверить, есть ли нужная модель телефона в наличии.
Зачастую это более простой вариант:
🤗 Все свои. Можно дойти до соседней команды или написать в личку;
🤗 Быстрее договориться о доработках;
😳 Более быстрый разбор ошибок.
Из минусов:
😒 Знания часто живут в головах и может быть плохо описанная документация;
💬 У другой команды свой бэклог и задачу могут взять в работу не так быстро, как хотелось бы;
🤓 Могут выкатить правки без предупреждения и молча сломать вам прод.
🌐 Внешняя (External)
Когда мы интегрируемся с системой вне нашей компании.
Пример:
У нас есть сервис авторизации и мы хотим, чтобы пользователь мог войти через Госуслуги или Google (внешние сервисы).
Из плюсов:
😋 Обычно есть подробная документация, которую можно изучить самому;
🔺 Есть чёткие правила и форматы данных, которые меняются не так часто.
Из минусов:
💀 Вы не влияете на процесс. Если они решили что-то поменять, вы просто подстраиваетесь, иначе всё сломается;
💀 Если внешний сервис упал, то разрабу в личку уже не напишите, придется писать в саппорт и ждать ответа.
2. Как: синхрон или асинхрон
📞 Синхронная интеграция (Request–Response)
Самый популярный вариант - REST, gRPC, SOAP.
Логика простая:
Запрос → Ожидание → Ответ. Пока мы не получим результат от другой системы, дальше не идем.
Пример:
Создали клиента → отправили запрос в систему проверок → ждем 5 секунд → получили статус «Одобрено» → создали личный кабинет.
Плюсы:
🎉 Всё просто: отправил - получил. Легко проектировать.
😊 Сразу понятно, на каком этапе возникла ошибка.
😌 Дернул метод через Postman и сразу увидел результат.
Минусы:
😅 Если вторая система упала, то процесс встал;
🤨 Любая задержка бьёт по пользователю.
Когда использовать:
👉 Ответ нужен здесь и сейчас (например, проверка баланса или авторизация);
👉 Пользователь смотрит в экран и не может продолжать работу без этих данных.
📨 Асинхронная интеграция (Event-Driven / MQ)
Kafka, RabbitMQ и другие брокеры сообщений.
Логика простая:
Отправили → Забыли. Нам не важно, когда именно другая система обработает данные. Главное, что мы зафиксировали событие и пошли дальше.
Пример:
Клиент нажал «Оформить заказ» → мы кинули событие в очередь → Склад начал сборку, а программа лояльности начислила баллы. Клиент сразу видит экран «Заказ принят», а не ждёт, пока отработают все внутренние сервисы.
Плюсы:
😏 Система не «тупит» в ожидании ответа, пользователь доволен скоростью.
😋 Если сервис почты упал, заказ всё равно оформится. Сообщение полежит в очереди и долетит позже, когда сервис поднимется.
👍 Можно легко добавить ещё пять систем-потребителей, и основной процесс от этого не замедлится.
Минусы:
🥲 Сложнее тестировать: приходится прыгать по логам разных систем, чтобы понять, где и почему застряло сообщение.
😉 Аналитику нужно продумать кучу нюансов: что делать с дублями сообщений (идемпотентность) и как не перепутать их порядок.
Самое простое объяснение:
Синхрон - вы звоните в ресторан.
Пока вам не подтвердят бронь, вы держите трубку.
Асинхрон - вы оставили заявку.
Администратор подтвердил её через 2 часа.
Вы не ждали у телефона.
Какой тип интеграций в ваших задачах встречается чаще всего? И что из этого больше всего бесит? 👇
IT АНАЛитика | Подписаться