Shared Fate

Shared Fate

https://giga.chat/link/gcskZAXFLs

Английское наименование: Shared Fate (Общая судьба).

Русская трактовка: Это концепция из области проектирования отказоустойчивых распределенных систем, которая описывает ситуацию, когда несколько независимых компонентов системы настолько тесно связаны или зависят друг от друга, что сбой одного компонента неизбежно и практически мгновенно приводит к неработоспособности всей группы.

В отличие от принципа «отсутствия единой точки отказа» (No Single Point of Failure), где компоненты изолированы, архитектура с «общей судьбой» подразумевает наличие скрытого общего ресурса или условия, гибель которого убивает всех его потребителей одновременно.

Механика возникновения

«Общая судьба» обычно возникает в одной из трех ситуаций:

1. Общий скрытый ресурс. Компоненты кажутся независимыми, но используют одну базу данных, один файловый диск или один канал связи. Если падает база — падают все сервисы, даже если их вычислительные мощности исправны.
2. Каскадный сбой (Cascading Failure). Один компонент перегружается и начинает отвечать медленно. Его клиенты (другие компоненты) ждут ответа, занимая свои потоки. Вскоре у клиентов заканчиваются ресурсы (память, CPU, свободные нити), и они тоже начинают падать или тормозить. Смерть распространяется как вирус.
3. Жесткая синхронизация. Компоненты должны работать строго согласованно (например, через протокол консенсуса вроде Raft). Если большинство узлов выходит из строя или теряет связь между собой, вся система останавливает запись данных, чтобы избежать расщепления мозга (split-brain). Судьба записи зависит от судьбы большинства.

Отличие от Изоляции (Isolation)

Чтобы лучше понять «Общую судьбу», полезно сравнить ее с противоположным подходом:

Характеристика	Общая судьба (Shared Fate)	Изоляция / Отказоустойчивость
Связь	Жесткая зависимость (High Coupling)	Слабая связь (Loose Coupling)
Реакция на сбой	Каскадное падение всей системы	Деградация (один модуль упал, остальные работают)
Пример	Все микросервисы подключены к одному экземпляру PostgreSQL без реплик.	Каждый сервис имеет свою БД или доступ к кластеру с автоматическим переключением мастера.
Философия	«Мы либо работаем вместе, либо умираем вместе».	«Я могу выжить, даже если мой сосед сгорел».

Почему это опасно?

Главная проблема «Общей судьбы» — эффект домино. Ошибка в одном некритичном модуле может обрушить критически важную часть бизнеса. Кроме того, такие системы крайне сложно тестировать на устойчивость (Chaos Engineering), так как нужно ломать именно общий фундамент, а не отдельные надстройки.

Как бороться с «Общей судьбой» в вашей архитектуре

Ваша текущая модель с FractalCellTemplate, BehaviorRouter и очередями уже содержит инструменты для минимизации общей судьбы:

1. Бюджетирование ошибок (Error Budgets) и Цепи размыкания (Circuit Breakers): Если одно поведение (PaymentBehavior) начало постоянно падать, оно не должно блокировать весь конвейер. Circuit Breaker вокруг этого поведения разомкнется, отсекая его от шины. Остальные поведения продолжат работу. Это разрывает общую судьбу ячейки и конкретного хендлера.
2. Изоляция ресурсов: Каждое поведение или группа поведений должна иметь свой ограниченный пул потоков или токенов пропускной способности. Если DataProcessingBehavior ушел в бесконечный цикл, он сожжет только свои токены, не заблокировав выполнение HeartbeatBehavior.
3. Отсутствие разделяемого изменяемого состояния (Shared Mutable State): Использование неизменяемых сообщений во InternalBus гарантирует, что одно поведение не сможет испортить данные в памяти, которые читает другое поведение.
4. Таймауты: Стратегия ILivenessStrategy, о которой мы говорили, по сути является механизмом выхода из «общей судьбы» зависимостей. Если внешняя БД стала недоступна, ячейка не ждет вечно (разделяя её судьбу), а признает себя неживой и перезапускается.