т.е. иметь 2 инстанса всего и реплицировать стейт?

Как мы знаем, такое бывает, если сначала думать, а не экспериментировать без знаний

Бывает, просто настолько дорого, что адепты данного подхода, как правило, сливаются задолго до столкновения с реальностью :)

Но да, с текущим рынком и низким уровнем вхождения в ИТ проще конечно признать возможность ошибки всюду, чем повальную некомпетентность

Ну как минимум того места где течёт…

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

Здесь соглашусь, что зачастую есть базовые проблемы в самих якорных платформах, от Команды не сильно зависящие…

А причем тут это? Можно взглянуть на количество кода в gcc/clang/jvm и баги в них.

Например, есть такой прекрасный генератор fsm как ragel. Один из самых быстрых генерируемых вариантов построен на goto. Для какого-нибудь smtp он выплёвывает код на 12-13к goto. GCC такое компилирует корректно, а clang выдаёт рабочий код только с выключением всех оптимизаций.

На -O1 там некорректный код, на -O2 и выше - сегфолт. И причём тут квалификация?

Конечно можно. Зависит от SLA

Условно, система работает 5 дней в неделю. Эти 5 дней она должна быть толерантной к отказам (отказоустойчивой). В другие 2 дня, можно обновлять хоть до посинения.

Пример - Биржи.

В чём может быть технически сложность? Стоят рядом 2 экземпляра монолита поверх одной базы данных и по очереди обновляются. Для большей надёжности базу можно реплицировать в другой ДЦ и туда же холодный stand in монолита. Это никакого отношения к разделению на микросервисы не имеет. Наоборот, обеспечить стабильность и отказоустойчивость монолита как бы не проще, чем толпы из N сервисов

ага, я как-то зациклился на  платформах уровня FAANG и региональных аналогов, почему и просмотрел такой простой вариант, спасибо.

А со схемой что?

И как с graceful degradation?

а) выдать какой-нибудь корректный ответ на стороне nginx в случае недоступности frontend'а
б) корректно обработать ошибку 500 на стороне frontend
ц) корректно обработать ситуацию недоступности базы данных... хотя тут уже проще ошибку 500

Ну я так подозреваю, что на graceful degradation  как раз другие бюджеты. :)

короче никак не связан graceful degradation и монолит / не монолит. И там, и там надо думать "а чо блин если "нет" ((с) Слепаков)?

Я всё-таки про сохранение функциональности ценой потери части функций

чтобы оно красиво отваливалось, тут имеется в виду, и чтобы юзеры не страдали, да. тут уж без усложнения никак.

Ну так пусть сохраняются. До тех пор пока у нас нет какого-нибудь менеджера скрытия неработающего функционала (вида "микросервис лёг — скрыть раздел на сайте") и менеджера наблюдения за состоянием всего остального каких-то особых отличий у монолита не будет. Но сложность такого сервиса и сложность его интеграции во frontend будет заслуживать отдельного стартапа. Подозреваю такой есть у FAANG, а всем остальным достаточно выдавать ошибку при непосредственной попытке обращения к сервису, чем скрывать факт наличия.