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

Уменьшение связанности компонентов? Горизонтальное масштабирование? Жёсткие требования по SLA и необходимость часто релизиться без простоя старых фич?

Коллеги, а как вы решаете проблему bus factor в условиях микросервисной архитектуры? Если для каждого микросервиса назначать мейнтейнера, то сложные продуктовые задачи, затрагивающие несколько микросервисов, становится тяжело планировать, поскольку непонятно, как именно в данный момент загружен мейнтейнер сервиса, сколько займёт времени тестирование и т.п. Также проблемы возникают, когда мейнтейнер уходит в отпуск или совсем.

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

Пока ехал в метро без связи перечитал исходный вопрос. В нем был акцент на bus факторе. Если вопрос именно в том как минимизировать боль ухода сотрудников...то мое первое сообщение эту проблему вообще не решало)) унификация технического стека, документирование архитектуры и дорожных карт... да и дробление сервисов на микросервисы может снизить риски, но повысит накладные расходы.

А любая фиксация процессов означает накладные расходы на поддержку этой фиксации.  Но упорядочивание работы может нивелировать эти расходы за счёт снижения стоимости исключаемых лишних работ

Да, вопрос баланса сложности проекта и уровня зрелости построенного процесса разработки. Что то можно успешно делать в хаосе, для каких то проектов нужны эволюционирующие процессы, дешевле выйдет :)