Multi-Region Architecture

Зачем

Все мечтают о multi-region пока не приходит счёт за egress и первый split-brain. Реально multi-region нужен в четырёх случаях, и ни один из них не звучит «на всякий случай»:

• HA против region-wide outage. AWS us-east-1 падает раз в 1-2 года на 2-6 часов. Если твой бизнес теряет $50K/час, multi-region окупается. Если $500/час — не окупается, бери multi-AZ.
• Latency-бюджет. EU-пользователь к us-east-1 — это +100ms RTT. Для gaming, ad-tech, real-time трейдинга это смерть. Для CRUD-админки никто не заметит.
• Compliance / data residency. GDPR, российский 152-ФЗ, китайский PIPL требуют, чтобы PII граждан хранилась в их юрисдикции. Это не оптимизация — это закон.
• Capacity. Один region упёрся в quota (vCPU, IP-адреса в VPC, S3 throughput). Редкий случай, чаще решается шардингом в пределах региона.

Если ничего из этого — ты в зоне false-economy. Multi-AZ single-region даёт 99.99% (53 минут downtime/год) за +20% к single-AZ. Multi-region даёт 99.999% (5 минут/год) за +200-300% к compute и +1000-10000% к network egress. Math простой: cost downtime должен превышать cost multi-region, иначе ты платишь страховку дороже, чем стоит застрахованное.

Mental model

Multi-region — это трёхмерный выбор одновременно по трём осям, и каждая ось независима:

1. Топология writes. Active-passive (один primary, остальные standby) vs active-active (все пишут). Это про consistency: AP проще, но при failover ты теряешь last writes (RPO > 0). AA сложнее (нужен conflict resolution), но zero-RPO.
2. Routing. GeoDNS (latency-based, Route 53) vs Anycast (BGP, Cloudflare) vs region-pinning (compliance). GeoDNS прост, но TTL мешает быстрому failover (RTO 5-15 мин). Anycast переключается за секунды (BGP convergence), но требует своего AS-номера и IP-блока.
3. Data layer. Async logical replication (Postgres) vs sync multi-master (Spanner, Cockroach) vs eventually consistent global (DynamoDB Global Tables, Cassandra multi-DC). Sync даёт consistency но добавляет cross-region RTT в каждый write. Async даёт latency но создаёт replication lag и risk потерь при failover.

Три оси — восемь комбинаций. На практике живых ~четыре:

• AP + GeoDNS + async replication — классический DR. Дёшево, RTO 5-15 мин, RPO секунды-минуты. Banking, healthcare.
• AA + Anycast + DDB Global Tables / Cassandra — global SaaS. Дорого, но RTO/RPO ~0. Netflix, Stripe, Shopify.
• Region-pinned + GeoDNS + per-region isolated DB — compliance. Каждый регион — своя замкнутая система. Никаких cross-region writes на PII.
• Read-local, write-global — единый primary в одном регионе, реплики в остальных только для чтения. Самый дешёвый AA-style компромисс, но writes медленные для дальних регионов.

Главный mental trap: думать «AA даст HA автоматически». Не даст. AA без conflict resolution + idempotent writes = data corruption при первом же partition. Если приложение не готово к eventual consistency и LWW (last-write-wins), AA опаснее AP.

Что на диаграмме

Три горизонтальных слоя сверху вниз: routing, regions (eu-west-1 и us-east-1), global data plane.

• Routing layer — два юзера (EU и US) и geodns нода. Это упрощённое представление: реально там Route 53 + health checks + опционально CDN edge (Cloudflare Workers).
• Region eu-west-1 содержит две вложенные группы: multi-AZ deployment (ALB + два app-сервера в разных AZ) и data plane (Postgres primary + Redis). Multi-AZ внутри региона — это базовая гигиена, не multi-region.
• Region us-east-1 зеркальная структура. В active-passive US-Postgres помечен как replica; в active-active обе БД — primaries; в data-residency у каждой свои данные.
• Global data layer — отдельная группа с DynamoDB Global Tables. Это иллюстрация multi-master eventually consistent storage, доступного из обоих регионов одновременно.
• Edges: пользователи → geodns → ALB своего региона → app-серверы → cache/db. Между регионами — async logical replication eu-db → us-db (одна стрелка, потому что в AP это один направление; в AA это была бы пара двунаправленных). DynamoDB Global Tables принимает writes из обоих регионов параллельно.

ADR-001 на ноде geodns фиксирует ключевое решение: multi-region vs multi-AZ. Все три сценария показывают разные topology поверх одной и той же диаграммы — переключай scenario pill в плеере.

Сценарии

active-passive-failover — DR с DNS failover. Happy path: EU primary обрабатывает трафик, US стоит standby и принимает async replication. Затем [OUTAGE] eu-west-1 down — flashError на трёх EU-нодах. Route 53 health check после нескольких проверок (обычно 30 сек) маркирует EU unhealthy, и DNS возвращает US IP. Но TTL=60s означает, что старые клиенты ещё 1-15 минут стучатся в мёртвый EU (DNS-кеши, корпоративные proxy). US replica промоутится в primary — и тут красный [RPO]: последние ~100ms writes EU-primary, которые не успели реплицироваться, потеряны. Это фундаментальное свойство async replication: zero-RPO требует sync, а sync убивает latency.

active-active-global-tables — multi-master через DynamoDB Global Tables. Оба региона одновременно принимают writes на один и тот же ключ user:42. EU пишет status=online, US — status=offline. DDB через ~1 секунду конвергирует, применяя LWW (last-write-wins по timestamp). Результат: US write выигрывает, но EU-клиент ещё видит stale online до прихода replication. Это и есть eventually consistent: система не врёт, она ещё не успела сказать правду. Для feed, counters, presence — ок. Для balance, inventory — катастрофа.

data-residency-gdpr — region pinning по compliance. GeoDNS маршрутизирует не по latency, а по country-of-origin (GeoIP). EU юзер всегда идёт в eu-west-1, его PII пишется в EU Postgres и никогда не реплицируется в US. Edge case: EU юзер летит в США и логинится оттуда — US-app получает запрос, но обязан сделать cross-region read обратно в eu-db. Лишние +100ms latency, но compliance соблюдён. Компромисс — кешировать в US-Redis не-PII поля (display name, preferences), а PII (email, phone, address) держать строго в EU.

Trade-offs (ADR-001)

Решение: single-region multi-AZ по умолчанию, multi-region только по жёстким триггерам.

Multi-region включаем, когда выполняется хотя бы одно:

1. Compliance требует data residency (GDPR EU-данные в EU, 152-ФЗ — в РФ).
2. Latency-бюджет жёстче 50ms p99 globally (gaming, ad-tech, HFT, real-time collab).
3. Cost downtime > cost multi-region. Считать в год: если час downtime стоит $50K, а multi-region добавляет $500K/год — невыгодно. Если час downtime = $500K (крупный e-commerce в Black Friday), то выгодно.
4. Regulatory DR в разных юрисдикциях (банкинг).

Топология под кейс:

• Banking / healthcare → active-passive. RTO 5-15 мин приемлем, RPO секунды через sync replication на горячий standby. Дёшево относительно AA.
• Global SaaS / e-commerce → active-active с DDB Global Tables или Spanner. RTO/RPO ~0, но сложно: нужны idempotent APIs, conflict resolution, ops-команда на 24/7.
• GDPR-heavy → region-pinned per-tenant. Никаких cross-region writes на PII.

Антипаттерн: multi-region «на всякий случай» для startup. Это технический долг и бюджет, который не оправдан. Multi-AZ + chaos engineering + хорошие runbooks решают 99% реальных проблем.

Реальные системы

• Netflix — active-active в трёх регионах (us-east-1, us-west-2, eu-west-1) через Cassandra multi-DC + Eureka для service discovery. Famous Chaos Monkey + Chaos Gorilla (убивает целый AZ) + Chaos Kong (убивает целый region) — регулярные drills.
• Stripe — region-pinned для compliance + active-active внутри региона. PCI-DSS требует, чтобы payment data не покидала юрисдикцию.
• AWS DynamoDB Global Tables — multi-master eventually consistent с LWW. До 2019 был single-master, теперь — symmetric multi-master. Used by Lyft, Disney, Samsung.
• Google Spanner / CockroachDB — global ACID через TrueTime / HLC (hybrid logical clocks). Sync replication через Paxos / Raft. Cross-region writes стоят 50-100ms из-за необходимости consensus.
• Cloudflare — anycast по всему миру, single IP routed via BGP к ближайшему edge. Failover за секунды через BGP withdrawal.
• Yandex / VK — multi-region внутри РФ + европейские DC отдельно для compliance (152-ФЗ).

Anti-patterns

• «Active-active без conflict resolution». Два региона пишут в общую БД через async replication, LWW не настроен — здравствуй, потерянные writes и corruption. Если решились на AA — определите conflict resolution до запуска, не после первого инцидента.
• «Multi-region для startup без revenue». $5K/мес на cross-region egress traffic при $10K MRR — это путь в гроб. Сначала multi-AZ, потом customers, потом multi-region.
• «Synchronous cross-region writes». Spanner-стиль consensus через два региона добавляет 50-100ms RTT к каждому write. Если throughput требует <50ms write latency — это блокер.
• «DNS failover без health checks на app-уровне». Route 53 проверяет TCP/HTTP на ALB, но не знает, что app внутри отвечает 500. Health endpoint должен проверять DB-connectivity, иначе DNS думает «всё ок», а юзеры получают ошибки.
• «PII в global replication». Реплицировать таблицы с email/phone/PII в US-replica для «удобства» = GDPR fine до 4% годового revenue. Per-region isolated DBs для PII или explicit pseudonymization.
• «Полагаться на TTL=300s в failover». 5 минут TTL означает 5-30 минут реального переключения (corporate DNS caches, ISP resolvers). Для быстрого failover — TTL=60s заранее + Anycast.
• «Не тестировать failover». Если регион никогда не падал в drill — он не failover-ready. Chaos engineering обязателен.

Когда НЕ использовать

• MRR < $1M, downtime cost < $5K/час. Multi-AZ покрывает 99.99%, бюджет идёт на features.
• Нет 24/7 ops-команды. Multi-region active-active требует команды, которая ночью разрулит split-brain. Без неё AA опаснее AP.
• Stateful система без идемпотентности. Если каждый retry создаёт дубликат (заказ, платёж) — AA даст double-charges при partition.
• Workload без global users. Если 90% юзеров в одной стране, multi-region даёт +0 пользе и +2-3× cost.
• Раннее MVP. Сначала product-market fit, потом scaling, потом HA. Premature multi-region убил больше стартапов, чем outages.

Дальше читать

• [CONCEPT]pacelc-theorem — расширение CAP: when Partitioned A vs C, else Latency vs Consistency. Multi-region — это PACELC в чистом виде.
• [CONCEPT]replication — sync vs async, leader-follower vs multi-master, lag и его последствия.
• [CONCEPT]dns — Route 53 routing policies, TTL, health checks.
• [CONCEPT]cdn-edge-network — Cloudflare, edge compute, как routing layer для multi-region.
• [CASE]instagram-system-design — global photo platform, multi-region delivery через CDN + region-aware writes.
• [CASE]twitter-system-design — global timeline, eventually consistent fanout в multi-DC.
• System Design Space: Multi-region global systems.
• AWS Well-Architected: Multi-Region Application Architecture (whitepaper).
• Google SRE Book: глава про global load balancing и Maglev.