Кейс: локальный кэш показывал разные данные на разных подах

Сервис держал Caffeine-кэш на уровне JVM для справочника тарифов — обновляется редко, читается на каждый запрос, поход в БД казался лишним. После правки тарифа в админке часть пользователей видела новую цену, часть — старую, и это не зависело от времени суток.

Причина — кэш локальный для каждого инстанса. Обновление тарифа писало в БД и инвалидировало кэш на том поде, который принял запрос от админки. Остальные три пода в кластере продолжали отдавать старое значение до истечения TTL, выставленного на шесть часов.

Локальный кэш ускоряет чтение, но у него нет механизма разослать инвалидацию соседям — это не Redis с единым состоянием, это N независимых копий одних и тех же данных.

Решили через Kafka-топик с событием invalidate-tariff: каждый под подписан и сбрасывает свою запись Caffeine при получении события, независимо от того, кто из подов принял исходное изменение.

Спросят следом: почему не сократили TTL вместо event-based инвалидации. Короткий TTL снижает окно неконсистентности, но не убирает его и увеличивает нагрузку на БД пропорционально частоте обновления — это компромисс, а не решение первопричины.

Локальный кэш в кластере из нескольких подов — это несколько разных кэшей, а не один.

Тренажёр: 600 вопросов, мок с таймером, план повторов

senior·base — что спрашивают на самом деле

В этом посте были ссылки, но мы их удалили по правилам Сетки