Краткий ответ

Нужен паттерн Bulkhead, или изоляция ресурсов: платёжный шлюз и каталог должны использовать независимые пулы соединений либо гарантированные квоты одного общего пула. Тогда исчерпание ресурсов каталогом не блокирует платежи.

Механизм не делает каталог доступным сам по себе. Он ограничивает область отказа и не позволяет одному потребителю занять все общие ресурсы.

Исторический контекст

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

В программных системах разделение ресурсов стало особенно важным при интеграции с медленными или ненадёжными внешними сервисами. Без такой изоляции локальная проблема одного вызова быстро превращается в отказ несвязанных функций.

Постановка проблемы

В исходном коде оба вызова используют один пул из 20 соединений. Если каталог зависает, его запросы удерживают соединения до тайм-аута; новые платежи не могут получить соединение и начинают ждать или завершаются ошибкой.

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

Подробное решение

Для независимых критичных функций задают отдельные ресурсные бюджеты:

paymentPool = ConnectionPool(size = 8)
catalogPool = ConnectionPool(size = 12)

function pay(request) {
    return paymentPool.call(PaymentGateway, request,
                            timeout = 2s)
}

function getCatalog(id) {
    return catalogPool.call(Catalog, id,
                            timeout = 1s)
}

Теперь зависший каталог может исчерпать только catalogPool. Платежи сохраняют доступ к своему пулу, хотя их собственные лимиты и внешняя зависимость всё ещё могут стать узким местом.

Изоляция может быть реализована отдельными пулами, очередями, группами потоков, лимитами конкурентности или отдельными экземплярами компонента. Важно изолировать не только соединения, но и связанные ресурсы: очереди ожидания, рабочие потоки, память и лимиты запросов.

Bulkhead обычно сочетают с тайм-аутами, ограничением очереди и быстрым отказом. Без тайм-аута занятый ресурс может удерживаться слишком долго; без ограничения очереди запросы продолжат накапливаться уже в памяти.

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

Изоляция не заменяет circuit breaker, повторные попытки или rate limiting. Circuit breaker прекращает вызовы временно недоступной зависимости, rate limiting ограничивает входной поток, а Bulkhead защищает соседние операции от исчерпания общих ресурсов. Повторные попытки без лимитов, наоборот, способны увеличить перегрузку.

Ситуация из практики

В интернет-магазине поиск каталога периодически замедлялся из-за деградации поискового индекса. Поиск и подтверждение платежа использовали общий пул HTTP-соединений, поэтому всплеск поисковых запросов приводил к тайм-аутам платежей.

Рассматривались три варианта. Увеличение общего пула было простым, но не устраняло конкуренцию и увеличивало нагрузку на внешние системы. Полный отказ от синхронного поиска снижал связанность, но требовал изменения пользовательского сценария. Установка только тайм-аутов ограничивала длительность ожидания, но не гарантировала платежам свободный ресурс при всплеске нагрузки.

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

Что кандидаты часто упускают

Достаточно ли разделить пулы соединений, чтобы получить полную изоляцию?

Нет. Запросы каталога могут исчерпать общий пул рабочих потоков, память, очередь задач или лимит исходящего трафика. Полная изоляция требует проверить весь путь выполнения и отделить наиболее значимые ограниченные ресурсы, а не только один тип соединений.

Почему большой общий пул не является эквивалентом Bulkhead?

Большой пул увеличивает суммарную ёмкость, но не устанавливает гарантированную долю ресурса для платежей. Один потребитель всё равно может занять все соединения при достаточном всплеске нагрузки. Bulkhead задаёт границу потребления, поэтому его свойство — контролируемая область отказа, а не просто больший запас производительности.

Когда отдельные пулы могут ухудшить систему?

Если квоты выбраны неправильно, один пул будет простаивать, пока другой постоянно перегружен. Кроме того, чрезмерная изоляция увеличивает сложность настройки и может снизить эффективность общего ресурса. Поэтому квоты должны опираться на критичность операций, реальные профили нагрузки и возможность безопасного отказа; для части ресурсов полезны динамические лимиты, но они не должны отменять гарантии для критичного потока.