Почему нельзя обращаться напрямую к Redis и зачем нужен сервис между клиентом и Redis
Что проверяют
Понимаете ли вы, что кэш это деталь реализации сервиса, а не общедоступное хранилище, и знаете ли ограничения самого Redis: модель доступа, однопоточное исполнение команд, отсутствие схемы.
Как отвечать
Начните с прав. У Redis нет разграничения доступа по владельцу данных: кто дотянулся до инстанса, тот видит все ключи и может выполнить FLUSHALL. Списки доступа появились, но они про команды и шаблоны ключей, а не про то, чьи это записи. Выставлять такой порт наружу нельзя, а сервис на Java умеет проверить токен, понять, чьи данные запрошены, и отдать только их.
Второй довод сильнее, и его чаще забывают: схема ключей это контракт. Пока в Redis ходит один сервис, он свободно меняет формат ключа, сериализацию и время жизни. Как только формат знают пять потребителей, поменять его нельзя без согласованной выкатки всех пятерых, и кэш превращается в публичный API без версионирования.
Третье это поведение под нагрузкой. Команды исполняются в один поток, поэтому тысячи прямых подключений, чужой KEYS по боевому инстансу или выборка огромного значения тормозят всех разом. Сервис держит пул соединений, ставит таймауты и метрики, а главное владеет инвалидацией и походом в базу при промахе. Без такого запасного пути отказ кэша сразу становится отказом продукта.
Где спотыкаются
Сводят всё к безопасности. Довод верный, но в закрытом контуре его легко парировать сетевыми правилами, а контракт схемы ключей никакими правилами не чинится.
Второе: называют Redis базой и предлагают писать в него как в источник истины. Тогда нужен разговор про надёжность записи и про вытеснение: при нехватке памяти выбранная политика выбросит ключ, который вы считали сохранённым навсегда.
Третье: считают прямое подключение более быстрым, потому что убирается лишний сетевой переход. Переход действительно убирается, но вместе с ним исчезают пул, таймауты и защита от лавины запросов при массовом промахе, и на пике это дороже сэкономленной миллисекунды.