Работали ли вы с кэшами, в том числе распределенными
Что проверяют
Понимаете ли вы, что кэш это обмен свежести данных на скорость, и умеете ли выбирать между локальным и распределённым. Простое перечисление продуктов ничего не даёт: спрашивают про инвалидацию и про поведение под нагрузкой.
Как отвечать
Разделите два уровня. Локальный кэш в куче процесса (Caffeine) даёт наносекундный доступ, но греется отдельно на каждом экземпляре и расходится между ними. Распределённый (Redis, Hazelcast) общий для всех узлов, стоит сетевого похода и требует сериализации. Часто их совмещают: короткий локальный поверх общего.
Дальше про схему работы. По умолчанию это cache aside: читаем кэш, при промахе идём в базу и кладём результат обратно. В Spring поверх этого есть абстракция с @Cacheable и @CacheEvict, но саму политику всё равно выбираете вы: время жизни, ограничение по размеру и вытеснение, инвалидация по событию изменения, версия в ключе вместо удаления. Назовите, что именно кэшируете и почему это допустимо: справочники и карточки товаров живут долго, а остатки на складе устаревают за секунды. Хорошо звучит пара инженерных деталей: не класть в общий кэш объекты стандартной сериализацией Java, иначе смена класса ломает чтение, и следить за долей попаданий, потому что кэш без метрик это догадка.
Где спотыкаются
Не знают про лавину промахов. Когда популярный ключ истекает, все потоки одновременно идут в базу и роняют её сильнее, чем без кэша. Лечится разбросом времени жизни, блокировкой на пересчёт или обновлением до истечения.
Считают кэш согласованным с базой. Между записью и сбросом ключа есть окно, а порядок важен: сначала запись в базу, потом удаление ключа, а не попытка обновить его вручную. Иначе пользователь видит старое значение после собственного изменения.
Отвечают процентами вместо механики. Снижение нагрузки на шестьдесят процентов без доли попаданий и без описания ключей не проверяемо. Туда же путаница между кэшем второго уровня ORM и кэшем приложения.