Multi-region architecture меняет модель high availability. Речь уже не про отказ AZ, а про отказ целого региона как единого домена.
До того как регион перестаёт быть надёжной границей отказа, классическая модель high availability строится вокруг multi-AZ: сбои железа, сети или DC изолируются внутри региона. Но эта модель предполагает, что регион выходит из строя только по техническим причинам и управляется провайдером. Геополитика ломает это допущение. Отключение интернета, санкции, ограничения на передачу данных или физические повреждения инфраструктуры создают коррелированные отказы (correlated failure), где весь регион становится недоступным сразу и без предсказуемого восстановления.
В этом контексте появляется более точная модель — sovereign fault domain (SFD). Это граница отказа, определяемая не архитектурой, а юрисдикцией, физической инфраструктурой и политическим контекстом. В отличие от AZ, SFD нельзя “спроектировать” или контролировать. Он существует независимо от системы. Это меняет постановку задачи: вместо “что если упадёт AZ?” возникает вопрос “что если регион станет юридически или физически недоступен?”. Для многих систем ответа на этот вопрос просто нет, потому что tooling и runbooks под него не рассчитаны.
Решение — переход к multi-region architecture как базовому уровню отказоустойчивости для систем, чувствительных к таким рискам. Здесь появляется выбор между active-passive и active-active. Active-passive даёт более простую модель и контроль над консистентностью, но увеличивает RTO из-за failover (DNS, health checks, promotion реплик). Active-active снижает RTO почти до нуля, но требует работы с eventual consistency и усложняет операционную модель. Это классический trade-off: latency и простота против доступности и скорости восстановления.
Реализация упирается в детали, которые часто недооценивают. Failover — это не одно действие, а цепочка задержек. Сначала detection через health checks, что может занять десятки секунд. Затем DNS propagation, зависящая от TTL и поведения резолверов. И наконец, promotion базы данных, где задержка зависит от replication lag. В реальных условиях именно последний этап становится источником сюрпризов. Тесты с нулевым lag редко отражают поведение под нагрузкой.
Отдельный слой сложности — данные. Geo-distributed системы делают CAP trade-off явным на уровне регионов. Сильная консистентность требует синхронной репликации, что увеличивает latency пропорционально расстоянию. Поэтому типичный компромисс — strong consistency внутри региона и eventual consistency между регионами. Но это работает только если система явно учитывает границы юрисдикций. В противном случае репликация, задуманная как механизм надёжности, становится источником compliance-рисков.
Практическая реализация требует “осознания суверенности” в data layer. Это может быть через возможности СУБД (например, placement policies или locality constraints) или на уровне приложения через маршрутизацию записей с учётом jurisdiction tag. Ключевая идея — запись должна подтверждаться внутри своей юрисдикции, а не в абстрактной “глобальной” системе. Системы, которые не различают эти уровни, обычно сталкиваются с проблемами в момент инцидента, а не на этапе дизайна.
Результат такого сдвига — более реалистичная модель отказов. Multi-AZ больше не является достаточным ответом на вопрос про high availability в глобальных системах. Multi-region становится необходимым, но вместе с этим растёт стоимость, сложность и требования к консистентности. Метрики выигрыша зависят от реализации и в исходном материале не указаны, но качественно меняется главное: система начинает учитывать отказ региона как нормальный сценарий, а не как исключение.