От Infinispan до Postgres на 1 ТБ: эволюция кэша поиска отелей

В сфере искусственного интеллекта произошло заметное событие. vadimbydanov 17 минут назад От Infinispan до Postgres на 1 ТБ: эволюция кэша поиска отелей Уровень сложности Средний Время на прочтение 7 мин Охват и читатели 831 Java * PostgreSQL * Высоконагруженные системы * Кейс Из песочницы Всем привет! Хочу рассказать, как мы небольшой командой проектировали кэш поиска отелей для сервиса по бронированию отелей и почему за полтора года прошли путь от Infinispan к managed Redis а затем к Postgres. По стеку java-21 , spring-boot-3 , 1 вендор отелей, расчетная нагрузка 1000 RPS и 10M запросов в сутки.

Дашборд кэша на этапе Infinispan. Дальше разберем, почему мы от этого ушли Пользовательская нагрузка сейчас средняя, мы проектируем систему под расчетную. История о том, почему managed Redis нам не подошел и как мы в итоге положили кэш в Postgres, а не о том, как выживали под миллионом запросов.

Технические детали

Что надо было сделать Пользователь приходит с запросом «Москва, 2 гостя, даты такие-то», мы идем к вендору, получаем ответ с сотнями отелей, отдаем обратно. Средний ответ 8-10 мб, на крупных городах доходит до 500 мб. Ходить за этим к вендору на каждый поиск долго и дорого.

Нужен кэш со следующими свойствами: кэшировать все пользовательские запросы. Ключ — слепок фильтров; прогреваться популярными запросами заранее, чтобы 80%+ поисков попадали в горячие данные и отдавались пользователю быстро; TTL для устаревших записей; метрики хитов и миссов через Prometheus + Micrometer TTL мы сразу поставили неделю. Это бизнес-решение, не техническое — устаревшая цена в рамках недели оказалась меньшим злом, чем промах и заставлять ждать пользователя, пока мы ходим к вендору Прототип на Infinispan Первая версия была максимально простая: Infinispan в одной ноде в докере, Spring Boot приложение, сериализация через protostream.

Кэш пишет все подряд: слепок фильтров запроса как ключ, JSON ответа как значение. Почему Infinispan, а не Redis? Redis тогда (в 2024) ушел из оперсорс, и было непонятно чем это кончится, а Infinispan Java-native и со Spring дружит из коробки.

Отраслевые последствия

Кстати, про сериализацию. Там был не совсем protobuf, как может показаться. По факту хранился JSON, который Infinispan оборачивал в protostream для совместимости.

Прогрев сделали простой: отдельный сервис по крону в 5 утра запускает список заданий и проходит их по порядку. Полный прогон занимает ~7 часов. Приоритизации городов нет, просто берем список популярных и прогреваем.

Что пошло не так С Infinispan в одной ноде в прод идти не хочется: в случае проблем может начать съедать память на диске и не чистить ее по TTL. Для прототипа на пре-проде это не беда, но каждую неделю разбираться с Infinispan, который забил диск никто не хочет. Провалы в попадании в кеш Каждые сутки кэш набивается прогревом до лимита, упирается в потолок и начинает вытеснять записи Решили, что хочется managed.

Этот прогресс даёт важные сигналы о будущем отрасли, и технологический мир внимательно наблюдает.