Как спланировать архитектуру проекта

Как спланировать архитектуру проекта

Самая распространненая ошибка при выборе архитектуры - ориентирование на бенчмарки.

Однако, если вы проектируете высоконагруженный проект ориентироваться надо на ССС:
Совокупная Стоимость Владения

Совершенно все равно за 10 милисекунд ответит БД под типовой нагрузкой, или за 20 миллисекунд.
Если вы потратите минимум 200 милисекунд на парсинг ответа и еще столько же на его отдачу.
По бенчмаркам - разница в два раза. Но мало кто считает цену.

ПО написанное на языке низкого уровня - сожрет Х памяти и Х процессорного времени
ПО написанное на JVM - сожрет 100X памяти и 100X процессорного времени
ПО на языке высокого уровня - сожрет 100000X памяти и упрется в своп. Или нет.

Просто загрузите на инстанс в амазоне все три варианта и дайте типичную нагрузку.

Амазон Вам выставит счет на X, 100X и 100000X долларов. Это прямые затраты.

Есть еще косвенные. Тут обратная ситуация:
Зарплата программиста на языке высокого уровня: $X/мес
Программист на JVM стоит - 5X/мес
На языке низкого уровня стоит те же 5X - но разработка аналогичного функционала займет у него 2X (те цена получается 10X)

И это тоже ещё не всё. Дальше начинают ролять архитектурные особенности ПО.

Допустим все ваши данные поместятся в 256 Гигов памяти с лихвой. Казалось бы - редис.
Но редис - однопоточный. Вы не купите сервак с 256 гигами оперативки и одним ядром. Вы заплатите за 24 или 48 ядер. А вот сможете ли эффективно утилизировать оставшиеся ядра - второй вопрос.
Или - например RocksDb - внутри оптимизация под SSD. SSD и HDD стоят совсем разных денег. Учитывать надо все.

И считать надо не столько и не только - сколько наносекунд уходит на операцию, а во сколько долларов обойдется эта операция.

Итак:
- Есть ли требуемый функционал
- Обеспечивает ли приемлемую скорость
- Надежность и масштабируемость
- Совокупная Стоимость Владения

Первые три пункта - это просто чеклист. Да или Нет. А последний - это ваши деньги.