Меняйте парадигму разработки, в подавляющем большинстве случаев переделать свое приложение можно с минимумом затрат.
Устаревший классический принцип - на каждый запрос к веб серверу приложение заново собирает данные из базы данных, шаблонов, формирует ответ и прочее, содержит в идеологии проблему вот этого повтора сбора данных, из-за которой приходится городить кеши.
Поднимите на базе php вебсервер (или даже вебсокет сервер или оба, react вполне себе технология, с плюшками от nodejs, асинхронщины и прочее) в том случае ваши данные будут всегда в оперативной памяти и контролируемы вами (т.е. вы можете управлять кешированием (управление блокировками) на уровне логики приложения, вплоть до полного хранения в оперативной памяти в переменных, а не базы данных как прослойки), само собой нет необходимости выставлять этот сервер в сеть, пусть проксирующим будет ваш основной вебсервер, контролирующий пользователей на уровне запросов и даже авторизации, а ваше react приложение - отвечать за логику.
Из недостатков подхода, полученный бонус к скорости заметно отдалит необходимость перехода к многопроцессорной реализации, так как по умолчанию это single thread приложение (но само собой никто не мешает вам запускать несколько бакенд но блокировками управлять так же придется с оглядкой на это), т.е. разрабатывая приложение об этом почему то многие стараются не задумываться сразу, типа зачем и так все круто, но потом будет больно.
В некоторых случаях скорость может подняться тысячекратно.
Классический же подход позволяет 'из коробки' использовать многопоточность и даже кластерную реализацию чуть ли не на администраторском уровне.
upd. исправил в ответе redis на react (глупо попутал термины)
