Как ускорить загрузку данных в системе с мобильным приложением и синхронным доступом

Что проверяют

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

Как отвечать

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

Дальше варианты, каждый со своими условиями:

• агрегация на сервере: слой BFF отдаёт экрану всё нужное одним запросом. На мобильной сети число запросов важнее объёма, каждый лишний обмен стоит десятки и сотни миллисекунд;
• параллельные вызовы: внутренние запросы, которые не зависят друг от друга, бэкенд делает одновременно, а не по очереди;
• меньше данных: пагинация по курсору, только нужные поля, сжатие gzip или brotli, картинки нужного размера через CDN;
• кэш на клиенте: локальная база в приложении, условные запросы с ETag и ответом 304 Not Modified, дозагрузка только изменений по метке updated_since;
• кэш на сервере: для медленных справочных систем, со временем жизни, согласованным с бизнесом;
• асинхронность: если результат не нужен сразу, запрос принимается с 202 Accepted, а готовность приходит пушем или опросом.

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

Где спотыкаются

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

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

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