Я подозреваю, что изобретаю велосипед, что проблема не нова как минимум, в мире онлайн-игр.

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

Ничто в мире не бесплатно. Плата здесь — аппликуха получает слегка подгнившие, иногда совсем некорректные данные.

Что я думаю, как это адресовать.
1) Хук в аппликухе по URL заглядывает в кеш у прокси, считывает дату данных и само тело- если оно существует и если дата не превысила срок годности, потому что если привысила- тогда прокси заставит аппликуху дожидаться ответа с бека в любом случае.
2) Если данные существуют в кеше и ещё не совсем протухли, тогда записывает в свой собственный аппликуховый LRU кеш объект и его дату стухания из прокси-кеша и запускает таймер скажем, на 10 секунд.
3) Через 10 секунд по таймеру, по одному, достаёт key-value в аппликуховом LRU, и сверяет дату стухания сохранённую с датой стухания в кеше. Если в кеше больше старой даты нет — выбрасывает key-value и переходит к следующему. Если в кеше старая дата стухания есть и она равна сохранённой в аппликуховом кеше — тогда переходит к следующему key-value.
Если в прокси-кеше дата стухания больше, чем сохранённая в аппликуховом, тогда выбрасывает из аппликухового кеша дату и объект, и сравнивает (deep equals) объект аппликухового кеша с объектом прокси кеша. Если объекты отличаются — тогда извещает подписчиков, что какие-то данные подгнили и нужно данные перезапросить с бека и обновить состояние аппликухи.
4) Если аппликуховый LRU непустой — снова запускается таймер на 10 секунд в пункт 3).

Вопрос- это слишком закручено и есть более прямые пути? есть какой-то паттерн проектирования, который описывает подобную оптимизацию отзывчивости приложения путём скармливания потенциально несвежих данных, не дожидаясь ответа с бекенда?