Использовались ли в репозитории кэширование и база данных
Что проверяют
Речь о слое Repository в архитектуре приложения, а не о Git: интервьюер хочет понять, как у вас были устроены данные и что было источником правды. Если формулировка кажется двусмысленной, уточните вслух. Следом обычно спрашивают, как вы инвалидировали кэш и что видит пользователь без сети.
Как отвечать
Каркас рассказа о своём проекте:
- источник правды: в офлайн-first подходе это локальная база. Room отдаёт данные через
Flowиз DAO, ViewModel передаёт их в UI, а сеть лишь обновляет базу. Экран не ждёт сети и сам перерисуется после записи; - уровни кэша: память (поле или
StateFlowв репозитории,LruCacheдля тяжёлых объектов), диск (Room для структурированных данных, DataStore вместоSharedPreferencesдля настроек), HTTP-кэш OkHttp по заголовкамCache-Control, кэш картинок в Coil или Glide; - инвалидация: срок жизни данных, принудительное обновление свайпом, стратегия «показать старое и тихо обновить». Для списков с пагинацией есть
RemoteMediatorиз Paging 3, для фоновой синхронизации WorkManager; - потоки и ошибки: сеть и база в корутинах вне главного потока (Room по умолчанию запрещает запросы с главного), ошибка сети не стирает уже показанные данные, миграции Room описаны явно.
Рассказывайте про свой проект: какие данные кэшировали, почему выбрали такой срок жизни, какой баг случился из-за устаревших данных и как его поймали. Нужны ваши примеры и цифры, например насколько быстрее стал открываться экран. Если в проекте была только сеть без базы, скажите прямо и объясните, как сделали бы кэширование сейчас и зачем.
Где спотыкаются
Отвечают «да, использовали Room» и перечисляют библиотеки. Интервьюера интересуют решения: где источник правды, как данные обновляются и когда считаются устаревшими.
Кэшируют без инвалидации. Пользователь неделями видит старые цены, а кнопки «обновить» нет.
Включают fallbackToDestructiveMigration(), чтобы не писать миграции. После обновления приложения локальные данные пользователя пропадают, включая неотправленные.