Проектирование интеграций
Интеграция — это то, как две системы обмениваются данными. Здесь чаще всего рождаются самые дорогие баги: потерянные сообщения, задвоенные заказы, зависшие синхронные вызовы. Аналитик проектирует обмен так, чтобы он выдержал сбои и рост нагрузки.
Ловушки называем сразу: выбор технологии до бизнес-потребности, синхрон путают с асинхроном, оркестрацию с хореографией, а брокер считают ускорителем синхронных вызовов. И почти всегда забывают про гарантии доставки и идемпотентность. Полная карта — в слоях ниже.
Карта темы
- Виды интеграций — API, брокеры и очереди,
ESB, файловый обмен и прямойDB-connect. - Топологии интеграции — точка-точка против звезды/шины и почему число связей взрывается.
- Синхрон, асинхрон и оркестрация — различие взаимодействий, оркестрация против хореографии и порядок проработки интеграции.
- Брокеры сообщений — зачем нужен брокер, гарантия доставки, dead-letter и обработка ошибок.
Частые ошибки и ловушки
| Ошибка | Последствие |
|---|---|
| Выбирать технологию до бизнес-потребности и данных | Проект переделывают, интеграция не решает задачу |
| Менять местами синхрон и асинхрон | Неверная модель поведения и связанности систем |
| Путать оркестрацию (центр) и хореографию (события) | Неверное распределение ответственности |
| Считать брокер ускорителем синхронных вызовов | Упущена его суть — развязка и асинхрон |
| Забыть гарантии доставки и идемпотентность | Сообщения теряются или применяются дважды |
| Утверждать, что точка-точка масштабируется даром | Число связей взрывается с ростом систем |
Значение для собеседований
Тему спрашивают, чтобы проверить, умеете ли вы проектировать надёжный обмен, а не просто назвать «REST и Kafka». Кандидат, который начинает с бизнес-потребности и объёмов, а гарантии доставки закладывает сразу, звучит как зрелый интеграционный аналитик.
Что обычно проверяют:
- Виды интеграций и когда что уместно (файл против API против брокера).
- Разницу синхрон/асинхрон и оркестрация/хореография.
- Зачем брокер: развязка, гарантированная доставка, сглаживание нагрузки.
- Порядок проработки проекта интеграции — от бизнес-потребности к обработке ошибок.
Типичный неверный ответ: «сначала выберем технологию, скажем gRPC, и напишем код». На самом деле проектирование начинается с бизнес-потребности, участников, регламента обмена и количественных показателей; технология — в конце.