Повышение производительности приложений: стратегии оптимизации сетевых запросов

Введение

Рост криптовалютной торговли многократно увеличил число пользователей. Для бирж вроде Coinbase это резкие скачки трафика: курс может измениться за минуты, а система обязана выдержать нагрузку без сбоев. Автомасштабирование баз, CDN-кеш и нагрузочные тесты — база. Чтобы реально масштабироваться, пришлось оптимизировать сетевые запросы на уровне мобильных и веб-приложений.

В этой статье — как Coinbase сократила избыточные вызовы API на 64% в часы пик, на 30% при инициализации приложения и на 40% в критических пользовательских сценариях. Приложения стали быстрее, нагрузка на инфраструктуру и расходы на масштабирование — ниже.

Это адаптированный перевод инженерного разбора Coinbase: не разовый «ускорить экран», а системная работа с over-fetching, опросом, кешем и защитными барьерами. Подход применим к любому клиенту на GraphQL или REST.

Почему важно сокращать число сетевых запросов?

Для пользователей. Быстрая загрузка — мгновенные транзакции. Меньше данных — приложение не «плывёт» на слабых устройствах. Стабильный UX повышает доверие к сервису.

Для бизнеса. Серверы выдерживают больше одновременных клиентов. Проще растить аудиторию. Меньше машин и трафика — ниже счёт за облако.

Архитектура Coinbase

Слой данных построен на Relay и GraphQL. Клиентский запрос через шлюз попадает в резолверы — функции, которые агрегируют данные из разных API. Один такой запрос может породить от 1 до 100+ внутренних вызовов микросервисов.

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

Три направления оптимизации

1. Борьба с избыточной выборкой

Лишние запросы чаще всего рождаются из неудачного API, неумеренного polling, выборки ненужных полей и мёртвого кода после A/B-тестов.

Проблема N+1 в API

На платформе много справочных данных: активы, цены, остатки. Для портфеля часто вызывали три сервиса подряд: список активов, затем цены, затем балансы. Классический N+1: вместо одного агрегированного запроса — пачка мелких.

Как решили:

• API принимает несколько параметров за один вызов.
• В резолверах — дата-лоадеры (пакетная загрузка).
• Списки отдают с пагинацией.

В отдельных местах число запросов упало почти на 90%.

Грамотное использование опроса (polling)

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

В React Native навигация оставляет старые экраны смонтированными. Если на главном экране опрос каждые 2 секунды по 40 запросов, а пользователь уходит вглубь стека на минуту, система сделает 1200 запросов впустую.

Рекомендации:

• Отписываться от опроса при потере фокуса экрана.
• Смотреть поведение: если на экране сидят меньше нескольких секунд, опрос может быть не нужен.
• Оценивать влияние на инфраструктуру в пиковые часы.
• Рассматривать альтернативы: WebSockets, push-уведомления, GraphQL subscriptions.

Запрос ненужных данных

• Условные фичи (например, только для пользователей из Великобритании) — сначала проверять страну. В GraphQL для этого есть директивы @skip и @include.
• Статичные данные вроде профиля — кешировать на клиенте.
• Большие списки (300 активов) — резать пагинацией, а не грузить целиком.

Инструменты кеширования: адекватный TTL, GraphQL-директивы политики кеша, CDN на границе, клиентский кеш и мемоизация React-компонентов.

Очистка мёртвого кода

После A/B-тестов и удаления фич важно вычищать неиспользуемый код вместе с запросами. Coinbase использует статические анализаторы, чтобы находить мёртвые модули и сразу убирать их из продакшена.

2. Оптимизация при пиковых нагрузках

В моменты волатильности рынка Coinbase прогнозирует всплеск и автоматически включает оптимизации через конфигурационный сервис. Цель — временно отключить некритичное и разгрузить бэкенд.

Что делают:

• Отключают упреждающую загрузку (оптимистичный fetch).
• Увеличивают TTL кеша на клиенте.
• Снижают агрессивность повторных попыток при ошибках.
• Отключают неключевые фичи (акции, промо) — в сильные движения рынка ими почти не пользуются.
• Включают облегчённые версии продуктовых функций.

В результате число запросов падает примерно на 64% без заметного ущерба для пользовательского опыта.

3. Защитные барьеры (guardrails)

Чтобы релизы не возвращали регрессии, контрольные точки стоят на всём пути: от клиента до шлюза, от GraphQL до сервисов, по типам запросов и платформам.

Новые метрики

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

Мониторинг и аномалии

Отслеживают число запросов при инициализации, на критический сценарий и на экран.

Пример регрессии: одно новое поле без A/B-теста добавило 20+ внутренних вызовов для всех пользователей. Мониторинг поймал это на этапе разработки, команда оптимизировала вызовы между сервисами до выкатки.

Результаты и выводы

За счёт описанных подходов Coinbase получила:

• −64% запросов в пиковые нагрузки;
• −30% запросов при старте приложения;
• −40% запросов в критических сценариях — это около 20% всего трафика к важнейшим сервисам.

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

Что можно взять на вооружение любой команде?

• Аудируйте сетевые паттерны — не только в пик, но и регулярно.
• Боритесь с N+1 — пакетные запросы, дата-лоадеры, пагинация.
• Скептически относитесь к опросу — отписывайтесь и ищите альтернативы.
• Кешируйте всё, что можно — на клиенте, на границе, в CDN.
• Внедряйте guardrails — метрики, мониторинг, контрольные точки.
• Автоматизируйте очистку — статанализаторы, PR-чеки, AI-ревьюеры.
• Делитесь знаниями — внутренние семинары и документация, чтобы практики жили не у одного человека.

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

Часто задаваемые вопросы

Почему важно сокращать число сетевых запросов?

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

Как Coinbase сократила запросы на 64% в часы пик?

Через конфигурационный сервис на пике отключают упреждающую загрузку, повышают TTL кеша, снижают агрессивность ретраев и выключают неключевые фичи. Критичные сценарии остаются, а лишний трафик падает примерно на 64%.

Что такое over-fetching и проблема N+1 в API?

Over-fetching — запрос данных, которые экран не показывает. N+1 — когда список активов тянет отдельный вызов цены и баланса на каждый элемент. Решение: пакетные параметры, дата-лоадеры в GraphQL-резолверах и пагинация. В отдельных случаях число запросов падало почти на 90%.

Когда polling вреден в мобильном приложении?

Когда частота слишком высокая и опрос не отключается вне фокуса. В React Native старые экраны остаются смонтированными: опрос каждые 2 секунды по 40 запросов за минуту вне экрана даёт 1200 пустых вызовов. Нужно отписываться при blur и рассматривать WebSockets, push и GraphQL subscriptions.

Какие guardrails не дают регрессиям уехать в прод?

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