Имеет ли смысл решать вопрос нагрузки в приложении?

Денис Гордиенко, руководитель Bright Mobile, о нагрузке на примере приложения для оптовых покупателей цветов.

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

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

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

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

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

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

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

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

Технологии

Для начала приведу список технологий, на которых делалось приложение:

Кроссплатформенная сборка дала плюсы в скорости и цене разработки. Требования к телефону у бизнес-приложения низкие и переплачивать за натив смысла нет. БД выбрана для работы в режиме реального времени — приложение держит соединение с базой по сокету и моментально получает обновления. Авторизация от Firebase даёт 10 тыс бесплатных СМС, что более чем достаточно для планируемой клиентской базы.

Пропадание списка товаров

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

К слову, у программистов всегда чешутся руки пооптимизировать запросы. Это хорошо, но важно понимать экономическую целесообразность. К примеру, при плановой нагрузке в 200 тыс чтений оплата составит $0,06 за 100 тыс чтений. То есть в сутки $0,09, это $2,7 в месяц.

Выгоднее платить по 167р в мес на платном тарифе, чем дополнительно заложить 40 часов разработчика на кеширование и пакетные запросы. Если ориентироваться на стандартную ставку в 1200р в час, то это добавило бы лишние 48 000р в бюджет.

Когда делать оптимизацию?

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

Предположим, что бизнес пошёл резко в гору и ежемесячно количество пользователей приложения увеличивается. Соответственно, незначительные 167р на текущем этапе будут постоянно расти. Обычно, сравнивая облачный FireStore коллеги приводят как альтернативу собственный сервер. Мол там нет аналогичной тарификации и можно не париться по количеству запросов.

Оставляю за скобками стоимость создания и развёртывания серверной архитектуры. Самый минимальный VDS можно взять примерно за 400р ($6,67) в мес, «нормальный» сервер — в районе 4000р ($66,67) в мес.

Адекватно задумываться об оптимизации было бы на этапе, когда эта самая оптимизация давала значительную выгоду перед арендой собственного сервера. То есть когда количество запросов к БД будет от минимальных 100 000 х $6,67 / $0,06 = 11 111 111 до «нормальных» 100 000 х $66,67 / $0,06 = 111 111 111.

111 миллионов запросов это достаточно абстрактная для бизнеса цифра. Поэтому переведём на заказы. В среднем, на одного пользователя, в этом приложении, чтоб он вдумчиво посидел и оформил корзину нужно 200 запросов к БД. То есть дойдя до платежа в 4000р в мес, клиент получит 10%(средняя конверсия в оплату) х 555 555 = ±55 555 заказов.

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