Здравствуйте, DiPaolo, Вы писали:

DP>Не зная твоих данных и их особенностей сложно что-то предлагать

DP>Что касается общеизвестных методов, то они легко гуглятся. Вот, к примеру, https://www.designgurus.io/blog/cache-invalidation-strategies
Да. Есть TTL и Stale-while-revalidate. Тема про Stale-while-revalidate.

DP>Единственное, я бы в твоем конкретно кейсе делал запрос с некоторой регулярностью (если это позволительно и данные не зависят от многих параметров) к бэку в отдельном треде, а не только когда данные понадобятся. Это сгладит длительность запроса для пользователя. В противном случае будет "то густо, то пусто".

Особенности такие: Web UI загружается медленно, крутит колёсиком ибо типа большая система. Потом он все запросы держит в памяти этой страницы, чтоб работать быстро. Там, когда данные записываются, есть логика чтоб кэши в памяти сбрасывались, это всё давно отлажено и вылизано. Там, когда данные изменены с другого компа — от пользователя ожидается, что он перезагрузит страницу, чтоб подхватить новые данные.

Новая фича — это кеш за пределами инстанса страницы, т.е. Web UI загружается мгновенно на старых закешированных данных.

Стратегия Stale While Revalidate: https://web.dev/articles/offline-cookbook#stale-while-revalidate

Прокси ревалидирует данные и записывает в прокси-кэш, но логика аппликухи ещё не допилена, чтобы обновить после revalidate.

Артикли, которые гуглятся у меня, все копи-паста с перечислением стратегий performance, freshness, staleWhileRevalidate но без рецепта по моему случаю с staleWhileRevalidate.