Можно устроить апокалипсис когда каждый сервис с другим сервисом общается на прямую, а можно через шину / брокера. Правда если шина / брокер упадёт или захлебнётся от нагрузки рисковое дело, шину можно балансировать, кластеризировать и т.д. В общем я наверное соглашусь с Владимиром, что чаще всего неумение работать, а не плохая БД, нам не дали денег, это проблема МИАЦ. Складывается мнение, что все виноваты вокруг кроме разработчиков или Прмоеда и / или еще вон того самого парня ...

ИТ-сфера Сбера или Тинькова вообще не интересует. Тот же Сбер сейчас занимается чёрте чем, но это не говорит что все их сервисы и внутренние системы связаны вместе. Я не знаю как обстоят дела в Сбере сейчас, но в 2010 году у них всё еще использовалось FoxPro для каких-то систем. И вообще внутренних систем было ооочень много, но между собой они никак не были связаны. Вполне допускаю, что сейчас СберГреф всё засунул в одну базу, на которую натравили нейросеть и теперь на основании этих данных они могут прогнозировать вспышки на солнце. В общем про этот идиотизм даже разговаривать не хочу. Но классически, в банках системы достаточно простые и не слишком связаны между собой. По сути для обслуживания клиентов нужна одна небольшая база с количеством средств у клиентов. Для кредитов еще одна база со своей спецификой. Для валютно-кассового обслуживания и продажи монет и слитков - еще одна база.

Подозреваю, что нагрузки на банковские системы несравнимо выше, чем на любую МИС. К тому же, в банковской сфере выше цена ошибки и поэтому в релиз не выкатывают плохо протестированные решения. Или просто изначально недоделанные (привет, ГИС ОМС, ЕГИСЗ СМП и прочие)

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

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

Оказал помощь, получил деньги. Всё просто)

Вопрос не в однотипности нагрузки, а в ее уровне. И процесс, я уверен, там намного сложнее, чем запрос к базе :) А операции клиента и прочие вещи, которые могут выбираться долго, без проблем отдаются в виде сформированного файла, когда он будет сформирован

Потому что есть регламент оказания услуги) в нем есть тайминг и процесс)

Тогда и железо должно быть соответствующее. Только вот минздравы почему-то выбирают железо по минимальным требованиям, с учетом работы например 3000 пользователей, а потом оказывается что пользователей 10000. Тут видимо тоже разработчики системы виноваты.

СМотря какая архитектура у системы, какой фронт вы предоставляете. Очевидно, что не всегда врачу нужно иметь информацию о пациенте с рождения до текущего момент. Можно порционно по потребности отдавать нужные данные. Я, с одной стороны, немного в теме, но рамках МИС только одной клиники. И у нас нет проблем со скоростью предоставления врачу данных. С другой стороны, я участвую в высоконагруженном проекте совершенно не по теме медицины и немного имеют представление о работе высоконагруженных систем )

Тогда и железо должно быть соответствующее. Только вот минздравы почему-то выбирают железо по минимальным требованиям, с учетом работы например 3000 пользователей, а потом оказывается что пользователей 10000. Тут видимо тоже разработчики системы виноваты.

Тут не архитектура системы влияет, а структура базы. Если нужно увеличить скорость, то либо добавляем оборудование, либо добавляем избыточность данных (денормализуем часть данных). И то и другое требует затрат на оборудование.