Вопрос проверяет умение балансировать между актуальностью данных и выигрышем в производительности при использовании кеша.
TTL выбирают исходя из того, как часто данные меняются и насколько критична их актуальность. Чем важнее свежесть, тем меньше TTL. Для редко меняющихся данных TTL может быть большим. Также учитывают нагрузку на источник данных и стоимость пересчёта. Неправильный TTL приводит либо к устаревшим данным, либо к бесполезному кешу.
TTL — это компромисс между скоростью, нагрузкой и корректностью данных.
TTL (time to live) — это время, в течение которого данные считаются валидными в кеше.
Перед перечислением важно зафиксировать: универсального TTL не существует.
Частота изменения данных
конфигурации
справочники
Бизнес-критичность актуальности
цены
статусы заказов
Стоимость пересчёта
сложные агрегации
тяжёлые запросы
Нагрузка на источник
БД
внешний сервис
Допустимая деградация
можно ли вернуть немного устаревшие данные
Короткий TTL
данные часто меняются
высокая критичность
Длинный TTL
статичные данные
дорогой пересчёт
Soft TTL
фоновой пересчёт
stale-while-revalidate
cache.set(key, value, ttl=300)
Один TTL для всего
Игнорирование бизнес-логики
Отсутствие инвалидации
TTL выбирается исходя из бизнес-требований и характеристик данных. Правильный TTL делает кеш полезным, неправильный — опасным.
