Не все пользователи живут в Wi-Fi и флагманах
Для части индийской аудитории смартфон — первый и единственный компьютер. Он может иметь мало памяти, старую версию Android и делить нестабильную мобильную сеть с целым районом. Интернет-магазин, спроектированный на офисном MacBook, здесь разваливается не из-за одной большой ошибки, а из-за сотни маленьких предположений.
Meesho прямо описывает свою задачу как продукт для миллиарда индийцев и заявляет, что приложение должно одинаково работать на low-end смартфонах и в low-bandwidth окружении. Это не техническая благотворительность: чувствительный к цене массовый рынок существует только при низкой стоимости обслуживания.
Производительность начинается с бизнес-модели
Если средний заказ небольшой, дорогая инфраструктура съедает маржу. Если приложение тяжёлое, пользователь не дождётся каталога. Поэтому скорость клиента, стоимость backend и качество рекомендаций становятся одной задачей.
Команда Meesho рассказывала, как во втором поколении ML-платформы заменила Cassandra на ScyllaDB, Redis-совместимый слой — на Dragonfly, а часть JVM-сервисов — на Go. По её данным, инфраструктурный след базы сократился примерно на 70%, память сервисов — примерно на 80%, а feature store выдерживал более миллиона запросов в секунду на распродаже.
Оптимизировать не бренд технологии, а нагрузку
Важен не вывод «Go всегда лучше Java». Meesho измерила собственные узкие места: большие heap, GC, потоки, горячие ключи, стоимость постоянно живущих данных в Redis. Затем сравнила альтернативы на реальном профиле.
Для небольшой команды переписывание языка ради моды почти всегда проиграет кэшу и двум исправленным N+1 запросам. Кейс полезен дисциплиной измерения: сначала профиль, затем архитектура.
Данные тоже можно греть по запросу
Команда заметила, что история взаимодействий пользователя нужна в быстром хранилище только когда он открыл приложение. Холодные события оставались в ScyllaDB, а в Redis загружались для активной сессии и позже выгружались обратно.
Этот приём шире ML. Не всё, что может понадобиться, должно постоянно лежать в самом дорогом слое. Горячее состояние определяется поведением пользователя, а не тревогой архитектора.
Мобильный интерфейс для плохого дня
На клиенте важны маленький первый пакет, локальный кэш, изображения нужного размера, скелетоны вместо пустого экрана и идемпотентные повторы заказа. При обрыве сети приложение должно сказать, отправлен ли платёж, а не предлагать нажать кнопку ещё раз и надеяться.
Каталог можно загружать порциями, фильтры применять локально к уже полученному набору, второстепенные рекомендации откладывать. Главный экран не обязан ждать десять независимых сервисов.
Среднее скрывает именно тех, для кого вы строите
Если половина аудитории открывает экран за секунду, а половина за девять, среднее в пять секунд не описывает никого. Meesho строит аналитику с разрезами по версиям приложения, регионам и устройствам, чтобы быстро находить деградацию после релиза.
Полезный dashboard показывает P75/P95 запуска, crash-free sessions и конверсию отдельно для дешёвых устройств и 3G/4G. Иначе команда улучшает опыт самых удобных для тестирования пользователей.
Что можно сделать за две недели
Купите два слабых Android-устройства. Ограничьте сеть в профилировщике. Запишите экран холодного запуска и оформления заказа. Установите бюджет размера приложения и изображений. Добавьте повтор запроса с идемпотентным ключом. Разрежьте метрики по памяти и версии ОС.
Meesho напоминает: массовый продукт — не дорогой продукт, который кое-как запустили на дешёвом телефоне. Это отдельная инженерная культура, где каждая лишняя секунда и мегабайт имеют цену.