Где еще можно хранить справочник кроме базы данных
Что проверяют
Умеете ли вы выбрать хранилище под характер данных, а не перечислить все знакомые технологии. Следом спрашивают, как обновить справочник без перезапуска и как не получить разные версии на разных инстансах.
Как отвечать
Начните с вопросов к самому справочнику: сколько в нём записей, как часто он меняется, кто его правит, нужны ли на него внешние ключи из таблиц. От ответов зависит выбор:
- код:
enumили константы. Годится для того, что меняется вместе с логикой, например статусы заказа. Любая правка идёт через релиз; - файл в ресурсах: JSON, YAML или CSV в
src/main/resources, читается при старте и версионируется в git вместе с кодом; - конфигурация:
@ConfigurationPropertiesв Spring Boot поверх Spring Cloud Config, Consul или etcd. С@RefreshScopeзначения перечитываются без рестарта; - кэш в памяти процесса: Caffeine с
refreshAfterWriteповерх любого источника. Самый быстрый доступ, но у каждого инстанса своя копия; - распределённый кэш: Redis или Hazelcast, одна копия на все сервисы ценой сетевого вызова;
- объектное хранилище: файл в S3-совместимом бакете, сервисы подтягивают новую версию по расписанию или по событию;
- отдельный сервис справочников: REST или gRPC, у данных один владелец, остальные кэшируют у себя;
- компактированный топик Kafka: хранит последнее значение по каждому ключу, сервис читает его в
GlobalKTableи получает изменения потоком.
Закончите рекомендацией: неизменное держим в коде, редко меняемое в конфиге или файле, а то, что правит бизнес, в базе или отдельном сервисе с кэшем поверх.
Где спотыкаются
Делают Redis единственным хранилищем. Без персистентности и с политикой вытеснения справочник однажды исчезнет после рестарта или под нагрузкой.
Кладут в enum данные, которые правит бизнес. Каждая смена тарифа или региона превращается в релиз.
Забывают про согласованность: у трёх инстансов три копии кэша, обновились они в разное время, и один запрос возвращает разные ответы. Нужна версия справочника или событие об обновлении.