Был ли опыт выстраивания сетевого слоя в высоконагруженных системах

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

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

Как отвечать

Отвечайте через свой проект: сколько активных пользователей, какие пики (распродажа, push-рассылка на всю базу), что ломалось. Цифры только реальные. Опорные пункты:

• стек: OkHttp как транспорт, Retrofit или Ktor Client поверх, корутины и Flow, kotlinx.serialization или Moshi для разбора ответов;
• один экземпляр OkHttpClient: общий пул соединений и HTTP/2, явные таймауты на подключение и чтение;
• интерсепторы: общие заголовки, логирование только в debug-сборке, Authenticator для обновления токена так, чтобы при десяти параллельных 401 ушёл один refresh, а не десять;
• ретраи: только для идемпотентных запросов или с ключом идемпотентности, экспоненциальная задержка с jitter, учёт Retry-After. Без jitter после сбоя вся аудитория разом ударит в только что поднявшийся бэкенд;
• кеш и офлайн: HTTP-кеш OkHttp по Cache-Control и ETag, Room как источник правды для экрана, отложенная отправка через WorkManager;
• трафик: пагинация через Paging 3, сжатие, никаких дублирующих запросов при пересоздании экрана;
• наблюдаемость: латентность и доля ошибок по эндпоинтам, чтобы видеть деградацию раньше отзывов в сторе.

Если настоящей нагрузки не было, так и скажите. Затем опишите, как спроектировали бы слой, и где уже применяли отдельные части.

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

Рассказывают, что приложение «выдерживало 10 000 одновременных запросов». Одновременные запросы держит сервер, клиенту эта цифра ничего не говорит, и интервьюер сразу спросит, как её мерили.

Отвечают про MVVM и RxJava. MVVM описывает UI, а вопрос про транспорт, ошибки и кеш.

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