Разделить систему на сервисы — внутреннее архитектурное решение. Если мобильному приложению для одного экрана приходится самостоятельно вызывать семь сервисов, учитывать их ошибки и склеивать ответы, сложность внутренней архитектуры просто переехала наружу.
API Composition решает эту проблему: отдельный слой или сервис вызывает нужные внутренние компоненты, объединяет результат и отдаёт клиенту один контракт.
Как работает решение
Компонент композиции знает, какие источники нужны для конкретного пользовательского сценария. Он делает несколько вызовов — последовательно или параллельно — и формирует единый ответ.
Это может быть отдельный endpoint, часть BFF, API Gateway или специальный orchestration layer. Важнее не название, а ответственность: клиент получает продуктовый ответ, а не карту внутренней системы.
Что получает бизнес
Главная выгода — возможность менять внутреннюю архитектуру с меньшим влиянием на клиентские каналы. Сервис можно разделить, объединить или заменить, пока внешний контракт остаётся стабильным.
Это снижает стоимость изменений и координации между backend и клиентскими командами. Новый экран или партнёрская интеграция меньше зависит от количества внутренних систем, которые участвуют в сценарии.
Ещё один эффект — более быстрый запуск сложных продуктовых сценариев. Клиентская команда работает с одним понятным контрактом вместо большого набора технических API.
Что получает команда
Frontend, mobile или внешние потребители получают меньше сетевой и orchestration-логики. Backend может централизованно решать, какие вызовы делать параллельно, где нужен fallback и как обрабатывать частичную недоступность.
При этом появляется новый компонент, который легко превратить в «бог-сервис». Если в него постепенно переносить бизнес-логику всех доменов, композиционный слой станет новым центром связанности.
Что получает клиент
Клиент получает меньше сетевых round trips и более предсказуемое поведение интерфейса. Особенно это заметно на мобильных сетях или при сложных экранах, где десятки последовательных запросов напрямую увеличивают задержку.
Также проще реализовать контролируемую деградацию: если второстепенный источник недоступен, композиционный слой может вернуть основной результат без него.
Чем мы за это платим
Появляется дополнительный слой, его нужно развёртывать, наблюдать и масштабировать. Он зависит сразу от нескольких сервисов, поэтому ошибки и задержки нижнего уровня могут складываться.
Нужно продумать таймауты, параллелизм, кэширование, обработку частичных ошибок и ответственность за контракт.
Кроме того, централизованная композиция может стать bottleneck организационно: если каждая команда обязана идти в один общий слой за любым изменением, скорость снова падает.
Когда не нужно
Если клиенту нужен один простой сервис или количество вызовов невелико, отдельная композиция может только добавить лишнюю сложность.
Она полезнее там, где один пользовательский сценарий действительно собирается из нескольких доменов и этот набор внутренних зависимостей не хочется раскрывать каждому клиенту.
Что стоит спросить перед решением
- Сколько внутренних сервисов должен знать клиент сегодня?
- Кто отвечает за внешний продуктовый контракт?
- Как поведём себя при частичной недоступности зависимостей?
- Не переносим ли мы бизнес-логику в слой композиции?
- Не станет ли этот слой новой очередью согласований?
В итоге
API Composition полезен не потому, что «склеивает JSON». Он проводит границу между внутренней архитектурой и тем, что должен видеть потребитель.
Для бизнеса это способ менять внутренние сервисы свободнее и не заставлять каждый клиент заново собирать продукт из технических деталей.