rPman

Подумай хорошенько, где ты собираешься кешировать и как инвалидировать кеш (проверять что данные в кеше устарели), получишь ответ на этот вопрос почти сразу

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

Дело в том что если твой бот как приложение, которое не завершает свою работу и единственное, кто обрабатывает реакцию пользователей, ему база данных на время его работы не нужна в принципе, все можно хранить в оперативной памяти нативно без прослойки, невероятно быстрой и эффективной. Но, так как сервера не надежны, приложения падают и т.п., данные все же хочется куда то писать, и вариант хранения данных в оперативной памяти дублируют (все изменения) в базе данных, и считываются в момент запуска.

Ну и если продолжать, вариант хранения всего в оперативной памяти может быть накладно если данных ну очень много (гигабайты.. сотни), с другой стороны у тебя бот, маловероятно что твоя клиентская база не поместится в сотню другую мегабайт.

Вот от сюда и думай, что хранить, где хранить надо ли делать запрос в базу или можно из памяти и т.п.

ctrl+f5
обновит страницу с принудительной загрузкой страницы и элементов

если у вас статика, смотрите настройки вебсервера, чтобы уменьшить интервал инвалидации данных в кеше

еще есть старый лайфхак, имя всех элементов на странице снабжать хешем, любым, криптостойкость не критична, типа styles.4f2dac.css тогда каждый раз новый файл будет иметь новое имя (но тогда нужна какая то автоматическая система контроля, которая будет подменять именя в коде, обычно это сама система сборки сайта)

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

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

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

Из недостатков подхода, полученный бонус к скорости заметно отдалит необходимость перехода к многопроцессорной реализации, так как по умолчанию это single thread приложение (но само собой никто не мешает вам запускать несколько бакенд но блокировками управлять так же придется с оглядкой на это), т.е. разрабатывая приложение об этом почему то многие стараются не задумываться сразу, типа зачем и так все круто, но потом будет больно.

В некоторых случаях скорость может подняться тысячекратно.

Классический же подход позволяет 'из коробки' использовать многопоточность и даже кластерную реализацию чуть ли не на администраторском уровне.

upd. исправил в ответе redis на react (глупо попутал термины)