Итак, вы сделали всё по учебнику: протестировали идею, собрали и проверили MVP, получили первые заказы и даже отзывы бета-пользователей. Кухня работает, курьеры на маршруте, корзины пополняются – кажется, можно открывать шампанское.

Но наступает вечер пятницы — и всё идёт не по плану: акция «2 по цене 1» валит сервер, курьеры не могут обновить статусы заказов из-за плохого интернета, крупный корпоративный заказ ломает оформление, а платежи замирают именно тогда, когда терминал должен работать без остановки. Минуты превращаются в потерянные заказы, остывшую еду, сорванные смены и недовольство клиентов.

Мелочи, которые не заметили на старте, часто убивают классные проекты быстрее, чем это успевают сделать конкуренты.

И чтобы этого не произошло, стоит задать себе несколько вопросов:

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

Почему заказ так и не доехал вовремя? Часто причина банальна: многие процессы внутри приложении завязаны на соединении с интернетом. Стоит ему пропасть, и весь флоу прерывается. Мы видели это видели на складах, где сканер штрихкода зависает из-за слабого Wi-Fi, на доставках, когда курьер заезжает в «мертвую зону» и статус заказа невозможно обновить в системе, на пунктах выдачи, где QR-код не пробивается, пока не вернётся соединение.

И в ходе разработки приложения для курьеров дарк-китчена Sizl в Чикаго заранее подумали об этом. При выполнении бесконтактной доставки курьер обязан отправить фото заказа, оставленного у двери, чтобы менеджер мог подтвердить завершение. Но без стабильного курьера соединения фото просто «зависало» в телефоне курьера, заказ не закрывался, а новые не уходили в работу.

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

Как реализовать offline-first подход с помощью React Native и RxDB, мы подробно описали в этой статье.

Для пользователя это значит одно: он может продолжать работать, не думая о сети. А для бизнеса – что процесс не «зависнет» из-за случайного обрыва связи, будь то в метро, в подвале склада или в пригороде с плохим покрытием.

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

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

Сдерживать наплыв помогают и фишки в UI/UX самого приложения. Например, в клиентском приложении Sizl мы добавили специальную плашку, которая отображается в пиковые часы, чтобы снизить количество потенциальных заказов и разгрузить кухню и курьеров.

Про другие особенности дарк китчена Sizl читайте в нашем кейсе.

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

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

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

Поэтому, даже если клиент введёт в поле «Адрес» смайлик с пиццей, заказ не исчезнет, а приложение спокойно отработает ситуацию и проведёт его до конца.

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

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

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

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

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

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

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

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

Посмотрите, как мы организовали интеграции со сторонними сервисами для маркетплейса Godno.

Чтобы рост трафика, непредсказуемые действия пользователей или падение сторонних сервисов не обернулись кризисом, закладывайте устойчивость ещё на этапе проектирования:

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