Системная архитектура и стек, используемые для больших приложений

Вот мои мысли по этому поводу:

• В целом к ​​системам с высоким уровнем риска (банковские приложения, биржи) должны предъявляться строгие требования с точки зрения безопасности, доступности, надежности, корректности. Если одна из этих особенностей не будет тщательно продумана, могут произойти плохие вещи (люди потеряют деньги). Обычно это приводит к более высоким затратам по сравнению с другими типами приложений.
• С точки зрения архитектуры, если вы хотите идти в ногу с текущими тенденциями, вы можете использовать микросервисы. Например, Monzo использует подход, основанный на микросервисах, для запуска своего бэкенда (эта красивая презентация содержит более подробную информацию). Это определенно новый способ создания масштабируемых серверных систем с малой задержкой (даже для приложений с высоким риском). Одним недостатком, который я вижу в этом подходе (могу ошибаться), является отсутствие зрелости (по сравнению с классической моделью клиент-сервер) и тот факт, что вам всегда нужно быть в курсе всех задействованных технологий с открытым исходным кодом, потому что они находятся в постоянном изменении. В крупных компаниях есть специальные команды, которые вносят свой вклад и остаются в курсе технологий с открытым исходным кодом.
• Вы всегда можете использовать архитектуру клиент-сервер, где бэкенд — это просто парк узлов, которые обрабатывают запросы и взаимодействуют с базой данных. Это может быть немного проще для начала, но, вероятно, сложнее развиваться. Выбор архитектуры полностью зависит от стратегии развития, которую вы планируете для своей системы. В любом подходе есть плюсы и минусы.
• Что касается технического стека, я бы выбрал зрелые языки/фреймворки, такие как Angular, Java, C#, Spring Boot. Таким образом, вам будет легче найти разработчиков, которые помогут вам, а также экосистему, созданную отраслью за эти годы.
• Что касается базы данных, вы можете использовать реляционное решение (MySQL, SQL Server) и использовать транзакции для предоставления атомарных обновлений (например, балансов счетов). В какой-то момент это может повлиять на общую производительность с точки зрения задержки/пропускной способности. Подход без SQL может повысить скорость, но также может привести к дублированию данных и некоторым проблемам с выбором правильной модели данных.

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