«Поведение пользователей во многих сервисах достаточно предсказуемо»

В первом полугодии 2026 года число платежей в интернет-магазинах Краснодара выросло на 66%, а оборот небольших площадок (с оборотом до 1 млн руб. в месяц) увеличился на 16%. Такие данные привели в пресс-службе ЮMoney. Для ИТ-инфраструктуры это означает кратное увеличение нагрузки. Почему цифровые сервисы могут начать тормозить именно тогда, когда бизнес растет, и почему попытка решить проблему увеличением числа разработчиков иногда только усугубляет ситуацию, рассказал Валентин Телегин, автор архитектурного решения для приложения телеком-оператора с аудиторией более четырех миллионов активных пользователей в месяц.

— Вы занимаетесь мобильной разработкой более 20 лет. Почему до сих пор остается актуальной проблема срыва сроков крупных ИТ-проектов?

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

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

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

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

— В какой момент руководителю разработки становится понятно, что проблема уже не в производительности конкретной команды, а в самой организации системы?

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

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

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

— Что обычно происходит в такой ситуации?

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

Вместо этого я предложил сформулировать задачу иначе: не «как получить данные быстрее», а «зачем пользователю вообще ждать данные, которые с высокой вероятностью еще не изменились».

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

— Как выглядит спроектированное вами решение на практике?

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

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

— Если можно прогнозировать, когда пользователю понадобится информация, зачем вообще ждать момента, когда он откроет приложение?

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

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

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

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

— То есть, вы фактически сделали систему «предугадывающей» запрос пользователя?

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

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

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

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

— Насколько сегодня изменилось само отношение к архитектуре мобильных разработок?

— Очень сильно. Когда я начинал, мобильная разработка сама по себе была довольно изолированной областью. Устройства были ограниченными, приложения — относительно простыми, а основная борьба шла за память, производительность и возможность вообще что-то сделать на конкретном телефоне.

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

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

Поэтому архитектура в крупных проектах — это уже не вопрос «как красивее написать код». Это вопрос управления будущей стоимостью системы. На мой взгляд, именно предсказуемость сегодня становится одним из главных признаков зрелой ИТ-разработки.

Беседовал Сергей Емельянов