Так это свободно

из-за того что в процессе работы виндовс кеширует свои апдейты

тогда норм

да, там жесткие конструкции были

и количество записей более 100000

ну тогда наверное тут больше вопрос к архитектуре..

нужна была скорость работы - так что кэшировалось все и вся на каждом этапе

ну мы тоже кешируем, только на hive, и норм)

разные проекты, разные объемы данных

для поиска есть elasticsearch

все остальное на “объемах” не работает

холиварное утверждение)

когда тот сервис работал, к которому было приложение - эластик под стол ходил.
Решение было именно для минимизации запросов на бэк, соответсвенно очень четко были синканы запросы всех клиентов, чтобы cdn хранил бандлы, клиенты получали только измененные.

это было андроид приложение. Получается есть ресайклер вью (или тогда это был еще листвью), список более 100 элементов. на каждый нужно собрать "карточку", срок обновления данных - минута. запрос на все - довольно "тяжелый" соответственно.
Решение - загрузить прекэш, и соответственно строить все локально из б.д., обновляя переодически кэш.

а бэк на чем был если не секрет? Сейчас вот смотрю в строну Rust вместо С#

этого я не знаю, я андроид клиент делал.

просто с такими костылями кажется что бэк был кривой)

сейчас на текущем - пацаны на node.js вообще фигачат.

приложение не просто список получить - отобразить -> по клику детальку показать.

делаешь на сервере заранее и отдаешь по запросу

много очень динамики было, видимо были свои особенности.