Сегодня распределённые архитектуры априори считаются более надёжными: избыточность, георепликация, изоляция отказов, независимые релизы, частичная деградация, быстрый откат — всё это снижает MTTR и удерживает SLO даже при частичных отказах. Это закреплено в «математике доступности»:
A = MTTF/(MTTF + MTTR), а снижение MTTR (авто‑митигация, быстрый роллбек) повышает A. Практики SRE прямо оптимизируют MTTR, чтобы выдерживать SLO.В больших организациях и глобальном трафике распределёнка объективно удобнее: масштабирование по географии, по нагрузке, по доменам. Монолит здесь часто упирается в организационные границы, темп релизов и физику одного процесса/БД. А распределённые системы проектируются, принимая во внимание компромиссы согласованности, отказоустойчивости и латентности.
Следите за руками. Что если сделать шаг в сторону и посмотреть на это, как на механику? В частности, как на эти два класса механизмов:
Классические механизмы — шестерни, шарниры, подшипники. Надёжность упирается в трение, люфты, загрязнение, допуски. Каждый узел вводит свою вероятность отказа, а суммарная надёжность пути для «чисто серийной» структуры равна произведению надёжностей узлов. Чем больше сочленений, тем ниже общий RR и короче ресурс между отказами. Для роликовых подшипников это ограничение проявляется как контактная усталость и конечный ресурс — классика расчёта срока службы.
Гибкие (Compliant) механизмы — цельные (буквально монолитные) конструкции, где движение рождается за счёт упругой деформации. Нет трущихся пар, следовательно почти нет износа, нет смазки, меньше компонентов, меньше концентраторов напряжений. В инженерной литературе это прямо формулируется как преимущества: «нет износа, нет люфтов и нет трения» (для рабочих амплитуд в пределах упругости), уменьшение числа деталей и сборочных допусков. В ряде приложений флексуры при корректном выборе материала/геометрии достигают практически бесконечного срока — если максимальные напряжения ниже предела выносливости.
И тут напрашивается такая аналогия:
Монолит — гибкий:
— Единый процесс и адресное пространство — минимум «сетевых шарниров».
— Инварианты локальны: границ меньше, контрактов меньше, поверхностей отказа меньше.
— «Износ» — это усталость «материала» системы (память, GC‑паузы, ресурсы ОС), а не эрозия API между сервисами.
— Надёжность растёт за счёт уменьшения числа последовательных узлов на критическом пути.
Распределёнка — ригидная:
— Шарниры = RPC/сеть (HTTP/gRPC, брокеры, балансировщики).
— Трение = латентность и джиттер; «износ» = таймауты, ретраи, пики повторов, эволюция контрактов.
— Люфты = несовместимость версий; вибрации = пиковые нагрузки, очереди, хвостовые задержки (p99/p999).
— Надёжность пути падает с каждым дополнительным вызовом; MTTR компенсируется операционными практиками (автоскейл, перезапуски, кворумы, деградация).
Вопрос. Если смотреть через призму «гибких механизмов», можем ли мы сознательно проектировать монолиты так, чтобы выигрывать в MTTF без обязательного роста MTTR? Например:
— Формировать «внутренние флексуры»: чёткие модульные границы внутри процесса, локальная асинхронность (in‑proc очереди), явные инварианты доменов.
— Держать «рабочую амплитуду» деформаций: ограничивать сложность критического пути, контролировать хвостовые задержки и бюджет памяти/CPU как предел усталости.
— Выносить настоящие «шарниры» только на внешний периметр — и там инвестировать в контрактные тесты, обратную совместимость и деградацию.
Где та самая седловая точка, после которой появление шарнира становится неизбежным, а где цельность даёт фундаментальный запас надёжности? Что мы увидим, если спроектируем системы как «гибкие механизмы» — и поднимется ли их надёжность на новый уровень?
Handbook of Compliant Mechanisms, An Introduction to Flexure Design
Чего только не придёт в голову, пока валяешься с ангиной.