Как минимизировать количество запросов к базе при частом обращении к параметрам

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

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

Как отвечать

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

• загрузка целиком в память: если параметров сотни или тысячи, проще прочитать таблицу одним запросом при старте в неизменяемую Map и при обновлении подменять ссылку целиком (volatile или AtomicReference). Чтения идут без блокировок;
• локальный кэш: Caffeine с expireAfterWrite или refreshAfterWrite. Второй вариант отдаёт старое значение, пока новое грузится в фоне, и не устраивает шквал запросов в момент истечения TTL;
• Spring Cache: @EnableCaching плюс @Cacheable на методе чтения и @CacheEvict на изменении. Без подключённого провайдера Spring Boot поднимает простой кэш на ConcurrentHashMap без TTL, поэтому провайдер лучше задать явно;
• инвалидация между узлами: локальные кэши на нескольких подах расходятся. Варианты: короткий TTL, событие об изменении через Redis pub/sub или Kafka, либо общий кэш в Redis;
• Hibernate: кэш второго уровня выключен по умолчанию, его включают через провайдер JCache и @Cache на сущности. Для запросов по параметрам нужен ещё query cache.

Отдельно проверьте, не N+1 ли это: чтение параметра в цикле или ленивая коллекция дают сотни одинаковых запросов, и лечится это JOIN FETCH, @BatchSize или одним запросом с IN.

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

Отвечают «добавим кэш» и молчат про инвалидацию. Через минуту спросят, как админка поменяет лимит на пяти экземплярах, и ответа нет.

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

Предлагают индекс. Он ускоряет каждый запрос, но их количество не меняет, а вопрос именно про количество.