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

M>Классического хайлоада больше нет. С одной стороны железо сделалось очень мощным, а с другой нагрузки перестали экспоненциально расти, как в эпоху развития интернета.

Согласен. Если раньше хай лоад был искусством профилирования и придумывания велосипедов, то сейчас в Java EE появился стандартный реактивный стэк Spring Reactor, основанный на идеях высокой нагрузки от Netflix, который из коробки умеет в хай лоад.
Есть всякие библиотеки типа Resilience4j с наборами хайлоад-паттернов (https://proselyte.net/protective-patterns/), которые условно позволяют превратить в хайлоад даже обычное старое легаси-приложение на блокирующем стеке, просто обвешав его снаружи аннотациями Resilience4j для соблюдения правил манифеста реактивных систем (https://www.reactivemanifesto.org/ru). Ещё в джаву подвезли легковесные потоки, которые могут вообще убить реактивный стэк (ввиду его сложности для освоения и контринтуитивности).
Главное понимать разницу межуд блокирующих стэком и реактивным, и понимать когда хватает и обычного блокирующего стэка (типа, если нагрузка не превышает 500 rps, то и блокирующий стэк справится). Если же все сервисы городить на реактивном стэке, это получится сложный в сопровождении золотой унитаз.
То же и с нагрузкой на БД, можно обойтись реляционной БД, в 90;% спасают обычные индексы, а если данных много, то сделав обычное прозрачное партицирование таблиц партманом, а не городить NoSQL базы, т.к. за нереляционую модель нужно платить (сложностью кода, слабой целостностью данных и рассинхроном на узлах по теореме CPA)