Поток запросов, событий или задач может расти быстрее, чем система способна их обработать. Это происходит во время рекламной кампании, массовой рассылки, сбоя downstream-сервиса или просто быстрого роста продукта.
Наивная стратегия — продолжать принимать всё. Очереди растут, память заканчивается, задержки увеличиваются, а затем деградирует уже не одна функция, а весь продукт.
Какую проблему мы решаем
Backpressure — это способ сказать источнику нагрузки: «быстрее сейчас нельзя». Ограничение может выражаться в паузе, уменьшении скорости, отказе от части запросов, лимите очереди или снижении приоритета.
Смысл не в том, чтобы сделать систему медленнее. Смысл — не позволить нагрузке расти бесконечно там, где физическая пропускная способность уже достигнута.
Хорошая система заранее знает, какие операции можно отложить, какие отклонить, а какие должны продолжать работать даже под давлением.
Что получает бизнес
Главная выгода — предсказуемое поведение в моменты перегрузки. Вместо неконтролируемой общей аварии бизнес получает управляемое ухудшение.
Это особенно важно, когда разные операции имеют разную ценность. Платёж, подтверждение заказа и авторизация могут быть важнее пересчёта рекомендаций или фоновой аналитики.
Backpressure также делает стоимость ёмкости видимой. Если очередь постоянно переполняется, это сигнал не «добавить ещё один retry», а пересмотреть мощность, приоритеты или сам бизнес-процесс.
Что получает команда
Команда получает явные границы нагрузки и меньше каскадных отказов. Очереди перестают расти бесконечно, а перегруженный consumer не тянет за собой всю инфраструктуру.
Но backpressure нужно поддержать протоколами и клиентами. Источник должен уметь замедляться или корректно обрабатывать отказ, иначе ограничение просто переносит проблему в другое место.
Что получает клиент
Клиент может получить более долгий ответ или редкий отказ вместо полного недоступного продукта. Это звучит хуже идеальной работы, но обычно лучше, чем ситуация, когда падает всё сразу.
Критично правильно объяснять повторяемость операций и не заставлять пользователя создавать дублирующие запросы из-за непонятного ожидания.
Чем мы за это платим
Нужно проектировать лимиты, размеры очередей, приоритеты и правила деградации. Появляется необходимость измерять lag и пропускную способность.
Слишком агрессивный backpressure начнёт отказывать раньше, чем это необходимо. Слишком мягкий — не спасёт от перегрузки.
Когда backpressure не нужен
Если нагрузка мала, поток ограничен естественным образом, а запас мощности большой, сложная система управления давлением может быть лишней.
Подход становится важным, когда есть очереди, streaming, нестабильные потребители или резкие пики нагрузки.
Что стоит спросить перед решением
- Какая операция должна выжить при перегрузке?
- Где допустима задержка, а где нужен быстрый отказ?
- Какой размер очереди ещё имеет бизнес-смысл?
- Умеет ли источник замедляться или повторять позже?
- Что произойдёт, если перегрузка длится не минуту, а час?
В итоге
Backpressure — это не про скорость. Это про контроль.
Для бизнеса это способ превратить перегрузку из неожиданной общей аварии в заранее определённый режим работы с понятными приоритетами.