Почему мобильное приложение — это не только интерфейс, но и инфраструктура

Экран — это вершина айсберга

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

Главная ошибка бизнеса — воспринимать мобильное приложение как «экран». Из этого вырастает заниженный бюджет, нереалистичные сроки и удивление, когда продукт начинает падать под реальной нагрузкой. Интерфейс — это 20–30% работы. Остальное — серверная часть, база данных, интеграции, безопасность, мониторинг и процессы обновления. Именно невидимая часть определяет, выдержит ли приложение тысячу одновременных пользователей, не потеряются ли платежи и сможете ли вы выпускать обновления без простоя.

Из чего на самом деле состоит приложение

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

• Клиент — то, что устанавливается на телефон. Отвечает за интерфейс, локальное хранение, офлайн-режим, кэш.
• API и серверная логика — обрабатывают запросы, применяют бизнес-правила, валидируют данные. Здесь живёт реальная «логика» продукта.
• База данных — хранит пользователей, заказы, транзакции. От её схемы и индексов зависит скорость всего приложения.
• Интеграции — платёжные системы (Click, Payme, Uzum), SMS-шлюзы, карты, госсервисы, CRM. Каждая внешняя система — это точка отказа.
• Инфраструктура доставки — серверы, контейнеры, балансировщики, CDN, очереди задач, фоновые воркеры.
• Наблюдаемость — логи, метрики, алерты, которые позволяют узнать о сбое раньше, чем о нём напишет пользователь.

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

Почему «работает на тесте» ≠ «работает в продакшене»

На устройстве разработчика приложение почти всегда летает. Один пользователь, быстрый интернет, пустая база, локальный сервер. Реальность другая: сотни одновременных сессий, медленные сети 3G в регионах, база на миллионы записей, пиковые нагрузки в час оплаты или в день зарплаты. Именно здесь проявляется качество инфраструктуры.

Запрос, который выполнялся 50 миллисекунд на пустой таблице, может занимать 8 секунд на таблице без индексов с миллионом строк. Сервер, который держал десять соединений, отказывает на тысяче, если не настроен пул соединений и кэширование. Платёж, который «прошёл» на тесте, в бою повисает между списанием денег и подтверждением заказа, потому что не была продумана идемпотентность и обработка таймаутов. Пользователь видит только крутящийся индикатор — но проблема не в кнопке, а в архитектуре.

Инфраструктура — это про деньги и репутацию

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

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

Безопасность и обновляемость — часть инфраструктуры

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

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

Как заказчику оценить, что инфраструктура продумана

Вы не обязаны разбираться в технологиях, но можете задать подрядчику правильные вопросы. Если на них есть внятные ответы — инфраструктура спроектирована, а не отложена «на потом».

• Где и как будут храниться данные, и есть ли резервное копирование с проверенным восстановлением?
• Что произойдёт, если упадёт платёжный шлюз или внешний сервис — потеряется ли заказ?
• На какую нагрузку рассчитана система и как она будет масштабироваться при росте?
• Как вы узнаете о сбое — есть ли мониторинг и оповещения?
• Как выпускаются обновления и что будет с пользователями старых версий?
• Как защищены данные и доступ к API?

Отсутствие ответов — не повод для паники, а повод обсудить эти вопросы до подписания, а не после первого падения в продакшене.