Как спроектировать приложение, чтобы «черная пятница» не превратилась в «черного лебедя»

  Статья подготовлена командой KODE

В июле 2025 года пользователи в России столкнулись со сбоями в системе быстрых платежей: операции проходили медленнее, возникали ошибки при авторизации в банковских приложениях. При этом регулятор не зафиксировал внешнего вмешательства.

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

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

Рост нагрузки — это не исключение, а норма

По мере цифровизации растёт и объём операций, которые проходят через приложения. Например, у «ВкусВилла» количество заказов через приложение выросло примерно с 3 тысяч до порядка 400 тысяч в сутки за несколько лет. На таком масштабе пиковые нагрузки становятся не исключением, а частью нормальной работы продукта.

И даже крупная инфраструктура не гарантирует, что проблем не будет. В 2021 году сбой произошёл у Wells Fargo: инфраструктура столкнулась с резким ростом запросов в период выплат. В 2023 году похожая ситуация произошла у HSBC во время «чёрной пятницы».

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

Как система начинает «сыпаться»

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

Дальше возникает эффект домино: один компонент системы начинает отвечать медленнее, из-за него растёт очередь запросов к следующему сервису, увеличивается время ответа — и проблема распространяется дальше.

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

Почему «чёрная пятница» превращается в «чёрного лебедя»

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

Если сервис стабильно обрабатывает текущую нагрузку, это ещё не означает, что он выдержит её кратный рост. Для таких случаев обычно закладывают запас производительности. Например, если система в пике получает 100 запросов в секунду, стоит заранее проверить её работу на 200–250 запросах.

Но сам по себе запас мощности проблему не решает. Важно понимать, какой компонент первым станет узким местом и что произойдёт дальше.

Балансировка помогает распределить нагрузку

Один из базовых механизмов устойчивости — балансировка трафика. Балансировщик распределяет запросы между несколькими экземплярами сервиса. Если один узел перегружен или недоступен, трафик можно перенаправить на другие. Это особенно важно потому, что нагрузка редко растёт плавно. Иногда за несколько минут количество запросов увеличивается кратно. Без распределения такой всплеск может попасть на один компонент и быстро вывести его из строя.

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

Нагрузочное тестирование нужно проводить до пика

Понять реальные пределы системы можно только с помощью тестирования. Важно заранее моделировать повышенную нагрузку и смотреть:

1. как меняется время ответа;
2. когда начинает расти количество ошибок;
3. где находится предел пропускной способности;
4. что происходит с очередями;
5. хватает ли соединений с базой данных;
6. какие компоненты деградируют первыми.

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

Chaos engineering: лучше сломать систему самим

Нагрузочное тестирование отвечает на вопрос, выдержит ли система большой поток пользователей. Но реальные аварии не всегда связаны только с количеством запросов. Может перестать отвечать внешний сервис. Упасть база данных. Замедлиться сеть. Закончиться ресурс одного компонента. Чтобы проверить такие сценарии заранее, используют chaos engineering — подход, при котором команда намеренно создаёт контролируемые сбои.

Например:

1. отключает отдельный сервис;
2. увеличивает задержки;
3. ограничивает ресурсы;
4. имитирует проблемы сети;
5. проверяет отказ базы или внешнего API.

Цель не в том, чтобы хаотично ломать продакшен. Команда заранее моделирует конкретную проблему и смотрит, сможет ли система продолжить работу.

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

Какие архитектурные решения помогают переживать пики

Устойчивость обычно складывается из нескольких механизмов.

Шардирование распределяет данные между несколькими узлами и помогает снизить нагрузку на отдельную базу.

Репликация позволяет иметь копии данных и переключать часть операций на дополнительные узлы.

Горизонтальное масштабирование даёт возможность увеличивать количество экземпляров сервиса при росте нагрузки, а не постоянно увеличивать мощности одного сервера.

Retry с backoff позволяет повторять неудачные запросы с увеличивающейся задержкой, а не отправлять их снова и снова без паузы.

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

Практика: как подготовиться к заранее известному пику

В одном из проектов KODE пиковая нагрузка была предсказуемой и привязанной к конкретной дате. Команда заранее провела нагрузочное тестирование и ввела запрет на релизы в критический период — за две недели до и после ожидаемого пика. Это снижало риск того, что новое изменение неожиданно повлияет на систему в самый нагруженный момент.

Архитектура была построена на изолированных сервисах, чтобы проблема одного компонента не распространялась на остальные. Инфраструктурой управляли через Kubernetes: он помогал распределять нагрузку и восстанавливать упавшие компоненты. Для базы данных использовали репликацию: операции записи шли на основной узел, а чтение — на реплики. Это позволило распределить нагрузку.

Когда система приблизилась к пределу производительности, команда дополнительно оптимизировала отдельные сценарии: сократила глубину запросов, увеличила использование кэша и ограничила объём данных, который пользователь мог получить за один запрос. В результате нагрузку удалось снизить без отказа от основного пользовательского сценария.

К пику нужно готовиться не в день пика

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

Нужно понимать пределы системы, регулярно проводить нагрузочные тесты, проверять аварийные сценарии и заранее решать, какие функции можно временно ограничить, чтобы сохранить главное. Тогда резкий рост нагрузки останется сложным, но управляемым событием, а не станет тем самым «чёрным лебедем», который останавливает весь продукт.