Как был выстроен сетевой слой в чате

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

Это вопрос о вашем опыте: понимаете ли вы, чем чат отличается от обычного REST-клиента. Реальное время, порядок сообщений, офлайн, повторные отправки. Следом почти всегда спрашивают, что происходит при потере сети посреди отправки.

Как отвечать

Рассказывайте про свой проект, опираясь на каркас:

• два канала: история и медиа через Retrofit поверх OkHttp, новые сообщения и статусы через WebSocket (newWebSocket в OkHttp или Ktor client). В фоне сокет не держат, система его всё равно убьёт, доставку берёт на себя FCM-пуш;
• переподключение: экспоненциальная задержка с джиттером, heartbeat через pingInterval, реакция на смену сети через ConnectivityManager.NetworkCallback, после реконнекта догрузка пропущенного по последнему id;
• Room как источник правды: UI подписан на Flow из DAO, сеть только пишет в базу. Для истории подходит Paging 3 с RemoteMediator;
• исходящие: у сообщения клиентский id и статус (отправляется, доставлено, ошибка). Id служит ключом идемпотентности, очередь неотправленного переживает перезапуск через WorkManager;
• корутины и сериализация: вызовы в viewModelScope или скоупе репозитория, kotlinx.serialization или Moshi, обновление токена через Authenticator в OkHttp.

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

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

Рассказывают только про Retrofit и @GET("messages"). Без реального времени и переподключения это не чат, а лента.

Запускают запросы в CoroutineScope(Dispatchers.IO).launch и ловят общий Exception. Скоуп ничем не управляется и течёт, а перехват глотает CancellationException и ломает отмену. К тому же suspend-методы Retrofit и так не блокируют главный поток.

Не продумывают дубли и порядок. Ответ на отправку потерялся, клиент повторил, собеседник видит два одинаковых сообщения. Порядок берут из серверного id или времени, а не из часов телефона.