Контекст
Cloud Native Overview
База по cloud-native принципам, поверх которых строится multi-region дизайн.
Multi-region / Global Systems - это проектирование сервисов, которые продолжают работать при отказе региона и дают предсказуемую задержку пользователям по всему миру. Главный инженерный вопрос здесь не только "как развернуть во многих регионах", а как сбалансировать latency, availability, consistency, compliance и стоимость.
Базовые multi-region topology
Когда подходит
Простой старт для большинства B2B/B2C систем с одним основным регионом.
Компромисс
Низкая операционная сложность, но выше RTO/RPO и неидеальная latency для пользователей вне primary-region.
Фокус эксплуатации
Автоматизация failover/failback и проверка целостности после promotion secondary.
Один регион обслуживает основную нагрузку, второй держится в standby и активируется при деградации primary.
Decision framework
- Latency budget: какое p95/p99 время ответа допустимо в каждом регионе.
- Availability target: какая деградация приемлема при падении целого региона.
- Consistency model: где нужен strict consistency, а где достаточно eventual.
- Data sovereignty: где физически можно хранить и обрабатывать данные.
- Cost profile: сколько стоит cross-region replication, egress и резервная ёмкость.
Theory
CAP Theorem
При глобальном partition архитектура должна явно выбрать приоритеты CP/AP.
Data layer: replication и consistency
Single-writer + read replicas
Хороший baseline для OLTP с понятной моделью консистентности и управляемым failover.
Multi-primary with conflict resolution
Подходит для write-heavy global workloads, но требует чёткой стратегии merge/last-write-wins/CRDT.
Regional sharding
Разделение tenant/data-domain по регионам уменьшает latency и стоимость, повышает изоляцию отказов.
Dual-write недопустим без coordination
Пишите через outbox/eventing или согласованный replication layer, иначе получите рассинхрон и потери.
Global traffic routing
- Geo DNS / latency-based routing для входящего глобального трафика.
- Health-aware traffic steering с быстрым исключением деградировавших регионов.
- Region affinity (sticky routing), чтобы сессии и кэш оставались локальными.
- Глобальный API gateway/edge слой с явными policy для fallback и partial outage.
DR, failover и операционная готовность
Определите RTO/RPO по каждому критичному сервису и базе данных.
Проверяйте failover/failback регулярно (game days), а не только на бумаге.
Автоматизируйте promotion secondary-region и проверку data integrity после переключения.
Держите runbook: кто, когда и по каким сигналам инициирует regional failover.
Разделяйте dependency graph, чтобы региональная авария не каскадировала глобально.
Без регулярных failover-тренировок multi-region архитектура часто остаётся "теоретически" отказоустойчивой, но не практической.
Связанные главы
Cloud Native Overview
Базовые принципы cloud-native архитектур и операционных практик.
Kubernetes Fundamentals
Механики multi-cluster, rollout и устойчивости workloads.
CAP Theorem
Фундаментальные ограничения распределённых систем при partition.
PACELC
Trade-off latency vs consistency не только во время сбоев.
Consensus Protocols
Как договариваться о состоянии в отказоустойчивом кластере.
Google Global Network
Эволюция глобальной сети и подходы к WAN как стратегическому активу.
Cost Optimization & FinOps
Как считать стоимость multi-region решений и долгосрочные компромиссы.
SRE и операционная надёжность
Инциденты, SLO и эксплуатация сложных production-систем.