Мульти‑регион для API: active‑active vs active‑passive, данные и консистентность

API может быть быстрым, аккуратно спроектированным и хорошо покрытым мониторингом, но всё равно оставаться уязвимым к одной простой вещи: зависимости от одного региона. Пока регион жив, всё выглядит спокойно. Но стоит появиться крупному сбою, сетевой деградации или проблеме у провайдера — и становится видно, была ли архитектура действительно отказоустойчивой или просто казалась такой на dashboard.

Мульти‑региональная архитектура звучит как очевидный ответ: запустить API в двух или более регионах и спать спокойнее. На практике именно здесь начинается самое интересное. Нужно решить, будут ли регионы работать одновременно или один станет резервным. Как маршрутизировать пользователей. Где хранить данные. Что делать с записью в базу. И, главное, какую консистентность можно позволить без ущерба для продукта.

Оглавление

• Что значит multi-region для API
• Два основных режима: active-passive и active-active
• Сравнение active-active и active-passive
• RTO и RPO: две метрики, которые быстро возвращают разговор на землю
• Главный вопрос multi-region: где живёт запись
• Модель 1. Single-writer: один регион принимает запись
• Модель 2. Multi-writer: каждый регион принимает запись
• Модель 3. Sharding по регионам или пользователям
• Консистентность: строгая, eventual и всё между ними
• Traffic routing: как пользователь попадает в регион
• Данные: самый сложный слой multi-region API
• Кэширование в multi-region: ускоритель или источник сюрпризов
• Очереди и фоновые задачи
• API contract: не скрывайте распределённость там, где она важна
• Active-passive: когда это правильный выбор
• Active-active: когда игра стоит свеч
• Практическая схема выбора
• Observability: что мониторить в multi-region API
• Failover нужно тестировать, а не обсуждать
• Deployments в нескольких регионах
• Security и compliance
• Типичные ошибки при проектировании multi-region API
• Мини-архитектура для старта
• Когда можно смешивать подходы
• Итог

Разберём всё по‑инженерному: без магии, без лозунгов про «пять девяток», зато с реальными компромиссами, которые всплывают при проектировании API для нескольких регионов.

Что значит multi-region для API

Multi-region — это подход, при котором API и связанные с ним компоненты развёрнуты в нескольких географических регионах. Например, один стек работает в Европе, второй — в Северной Америке, третий — в Азии.

Но важно не путать multi-region с обычной высокой доступностью внутри одного региона. Если сервис запущен в трёх availability zones, это хорошо защищает от сбоя отдельной зоны. Но если падает весь регион, такой дизайн уже не спасает.

Multi-region нужен, когда команда хочет выдержать более крупные проблемы:

• недоступность региона у облачного провайдера;
• сетевую деградацию между пользователями и регионом;
• требования к disaster recovery;
• снижение latency для глобальной аудитории;
• регуляторные ограничения по хранению данных;
• плановые миграции без полного downtime.

Мини‑пример: API для панели управления хостингом работает только в одном европейском регионе. Пользователи из США видят повышенную задержку, а при сбое региона весь control plane становится недоступным. Multi-region может решить обе проблемы, но не бесплатно: за устойчивость придётся платить сложностью.

Два основных режима: active-passive и active-active

Когда говорят «у нас multi-region», за этим могут скрываться совершенно разные архитектуры. Самое важное разделение — active-passive и active-active.

Active-passive: один регион работает, второй ждёт

В active-passive модели один регион обслуживает production-трафик. Второй регион находится в резерве: он может быть полностью готовым, частично развернутым или минимально подготовленным.

Если основной регион падает, трафик переключается на резервный.

Представьте магазин с основной кассой и запасной кассой рядом. Обычно работает только первая. Вторая включается, когда первая ломается или очередь становится критичной. Она есть, но большую часть времени не участвует в обслуживании.

В API‑архитектуре это может выглядеть так:

• Region A принимает все запросы;
• Region B получает репликацию данных;
• инфраструктура в Region B готова к запуску или уже запущена;
• DNS, global load balancer или traffic manager переключает пользователей при failover.

Active-passive часто выбирают для disaster recovery. Это понятная модель, которую проще внедрить, проще тестировать и проще объяснить бизнесу.

Active-active: все регионы работают одновременно

В active-active модели два или более региона одновременно обслуживают production-трафик.

Пользователь из Германии может попасть в регион Frankfurt, пользователь из США — в Virginia, пользователь из Сингапура — в Singapore. Если один регион становится недоступен, traffic routing переводит запросы в другие живые регионы.

Звучит красиво. И действительно, active-active даёт заметные преимущества:

• ниже latency для глобальной аудитории;
• нет «холодного» переключения на резерв;
• резервный регион постоянно проверяется реальным трафиком;
• сбой одного региона может быть менее заметен для пользователей.

Но active-active — это не просто «скопировать API во второй регион». Compute обычно копируется относительно легко. Настоящая сложность начинается с данных.

Сравнение active-active и active-passive

Выбор между active-active и active-passive лучше делать не по принципу «что звучит круче», а по требованиям продукта.

Здесь нет универсального победителя. Active-passive может быть разумнее для команды, которой важен надёжный DR без лишней сложности. Active-active нужен там, где downtime и высокая задержка стоят дороже, чем сложность архитектуры.

Хороший вопрос для старта: вы строите multi-region ради восстановления после аварии или ради постоянной глобальной работы?

RTO и RPO: две метрики, которые быстро возвращают разговор на землю

Перед выбором паттерна нужно договориться о двух вещах: сколько downtime допустимо и сколько данных можно потерять.

RTO: как быстро сервис должен восстановиться

RTO — Recovery Time Objective. Это максимальное время, за которое сервис должен вернуться в рабочее состояние после сбоя.

Если бизнес говорит: «API может быть недоступен до 30 минут», active-passive с warm standby может быть достаточным.

Если ответ: «Downtime почти недопустим, пользователи должны продолжать работу», разговор быстро смещается к active-active или очень хорошо автоматизированному hot standby.

RPO: сколько данных можно потерять

RPO — Recovery Point Objective. Это допустимая потеря данных во времени.

Например, RPO 5 минут означает, что в худшем случае можно потерять изменения за последние 5 минут. Для логов это иногда приемлемо. Для платежей — почти никогда.

Именно RPO часто ломает красивые схемы на презентациях. API можно поднять во втором регионе быстро. А вот гарантировать, что все данные там актуальны, — совсем другая задача.

Главный вопрос multi-region: где живёт запись

Для API чтение обычно масштабировать проще. Можно поставить кэш ближе к пользователю, использовать read replicas, CDN, edge, региональные копии данных.

Запись сложнее. Когда пользователь меняет пароль, создаёт заказ, оплачивает счёт или обновляет конфигурацию сервера, система должна решить: где находится источник правды?

Есть несколько популярных моделей.

Модель 1. Single-writer: один регион принимает запись

В single-writer архитектуре только один регион является главным для записи. Остальные регионы могут обслуживать чтение или часть API, но все операции записи отправляются в primary region.

Это распространённый вариант для active-passive и иногда для active-active на уровне compute.

Пример:

• пользователи из разных стран попадают в ближайший API‑регион;
• read-запросы обслуживаются локально;
• write-запросы проксируются в primary database region;
• данные реплицируются обратно в остальные регионы.

Плюсы:

• меньше конфликтов;
• проще reasoning;
• легче обеспечить строгий порядок изменений;
• проще аудит и восстановление.

Минусы:

• write latency выше для удалённых пользователей;
• primary region остаётся критичной точкой;
• при сбое primary нужно выполнять failover записи.

Аналогия простая: филиалы компании могут читать локальные копии документов, но подписывать договоры разрешено только в головном офисе. Не всегда быстро, зато понятно, где оригинал.

Модель 2. Multi-writer: каждый регион принимает запись

В multi-writer модели несколько регионов могут одновременно принимать изменения.

Это ближе всего к настоящему active-active. Пользователь пишет в ближайший регион, а изменения реплицируются в остальные.

Звучит идеально: низкая latency, высокая доступность, нет единственной точки записи. Но появляется вопрос: что делать, если два региона изменили одну и ту же запись почти одновременно?

Например:

• пользователь открыл профиль в Европе и США через разные сессии;
• в Европе он изменил email;
• в США почти одновременно изменил phone number или тот же email;
• обе записи ушли в локальные базы;
• репликация встретилась позже.

Какое значение считать правильным?

Варианты конфликт‑resolution бывают разные:

• last write wins;
• merge по полям;
• version vectors;
• application-level reconciliation;
• ручной разбор;
• запрет одновременной записи через ownership или partitioning.

Multi-writer требует, чтобы приложение понимало распределённую природу данных. Просто включить репликацию и надеяться на лучшее — плохой план.

Модель 3. Sharding по регионам или пользователям

Иногда лучший способ избежать конфликтов — не давать нескольким регионам владеть одними и теми же данными.

Например:

• европейские клиенты закреплены за EU region;
• американские клиенты — за US region;
• азиатские клиенты — за APAC region.

Каждый регион является primary для своей части данных. Остальные регионы могут иметь read-only копии или вообще не хранить эти данные.

Это похоже на систему с несколькими офисами, где каждый офис отвечает за своих клиентов. Если клиент из Европы обращается в американский офис, запрос всё равно маршрутизируется к европейскому владельцу данных.

Плюсы:

• меньше конфликтов;
• проще compliance;
• ниже latency для локальных пользователей;
• понятное ownership данных.

Минусы:

• сложнее global reporting;
• сложнее миграция клиента между регионами;
• нужно правильно проектировать routing;
• cross-region операции становятся дороже.

Для B2B‑API это часто очень практичный вариант. Особенно если клиентские данные можно естественно разделить по tenant, account или organization.

Консистентность: строгая, eventual и всё между ними

Консистентность — это не абстрактная академическая тема. Это ответ на простой пользовательский вопрос: «Почему я только что изменил настройку, а в другом регионе вижу старую?»

Strong consistency

Strong consistency означает, что после успешной записи все последующие чтения видят актуальное значение.

Для пользователя это самый понятный вариант. Нажал «Save» — везде сохранилось.

Но в multi-region мире strong consistency часто стоит дорого. Чтобы гарантировать единое состояние между удалёнными регионами, системе нужно синхронизироваться через сеть. А сеть между континентами не мгновенная.

Чем дальше регионы, тем выше latency. Физику не обмануть красивой диаграммой.

Strong consistency особенно важна для:

• платежей;
• балансов;
• лимитов использования;
• уникальных идентификаторов;
• прав доступа;
• критичных операций управления инфраструктурой.

Если нельзя показать пользователю устаревшие данные даже на секунду, придётся платить latency, сложностью или ограничением write-модели.

Eventual consistency

Eventual consistency означает: данные разойдутся по регионам не мгновенно, но со временем придут к согласованному состоянию.

Для многих сценариев это нормально.

Например:

• обновление аналитики;
• список последних действий;
• delivery статусов;
• статистика потребления;
• кэш профиля;
• рекомендации;
• поисковые индексы.

Пользователь может пару секунд видеть старое значение, и продукт от этого не ломается.

Но eventual consistency нужно честно учитывать в UX и API‑контрактах. Если после POST клиент сразу делает GET из другого региона и ожидает новое значение, система должна либо обеспечить read-your-writes, либо объяснить задержку.

Read-your-writes

Read-your-writes — удобный компромисс. Пользователь после собственной записи видит свои изменения, даже если глобальная репликация ещё не завершилась.

Как это сделать:

• закрепить пользователя за регионом после записи;
• читать критичный объект из primary region;
• использовать session affinity;
• возвращать обновлённое состояние прямо в ответе на write;
• применять client-side versioning или ETag.

Мини‑пример: пользователь меняет тарифный план. API возвращает новый план в ответе на PATCH /subscription, а следующие запросы в течение короткого времени идут в тот же регион. Пользователь не видит «отката» интерфейса назад, даже если другие регионы ещё догоняют.

Traffic routing: как пользователь попадает в регион

Multi-region API начинается не с базы данных, а с входной точки.

Кто решает, куда отправить запрос?

Обычно используются:

• DNS‑based routing;
• global load balancer;
• Anycast;
• CDN или edge network;
• API gateway с глобальным маршрутизатором;
• custom routing logic на уровне клиента.

Latency-based routing

Пользователь направляется в регион с минимальной задержкой.

Это хорошо для глобальных продуктов. Но если данные пользователя живут в конкретном регионе, latency-based routing может привести к лишним cross-region запросам.

Например, пользователь из Германии временно находится в США. Ближайший регион — US, но его account хранится в EU. Если API отправит его в US, запрос всё равно пойдёт за данными в EU. Иногда лучше сразу маршрутизировать по data ownership, а не по географии клиента.

Geo-based routing

Запрос отправляется на основе географии пользователя.

Это удобно для compliance и data residency. Например, все пользователи из EU идут в EU region.

Но география по IP не всегда идеальна. VPN, corporate proxies, mobile networks и спутниковые провайдеры могут ломать картину. Поэтому geo-routing лучше использовать аккуратно и иметь fallback.

Health-based failover

Routing должен учитывать здоровье региона.

Если регион отвечает медленно, возвращает 5xx или теряет связь с базой, traffic manager должен уменьшить или остановить поток запросов туда.

Здесь важно проверять не просто /health, который отвечает «ok». Нужны глубокие health checks:

• API process жив;
• база доступна;
• очередь работает;
• зависимые сервисы доступны;
• write path не сломан;
• replication lag в допустимых пределах.

Иначе можно получить неприятную ситуацию: load balancer считает регион здоровым, потому что nginx отвечает 200, а приложение внутри уже не может записывать заказы.

Данные: самый сложный слой multi-region API

Compute можно развернуть через Terraform, Helm, Ansible или CI/CD pipeline. Образы контейнеров можно доставить в несколько registry. Конфигурацию можно хранить в Git.

Данные так просто не копируются.

Репликация

Репликация может быть синхронной и асинхронной.

Синхронная репликация даёт более строгие гарантии, но увеличивает latency и чувствительность к сетевым проблемам.

Асинхронная репликация быстрее для пользователя, но создаёт replication lag. В момент сбоя часть последних записей может ещё не успеть попасть во второй регион.

Для active-passive часто используют асинхронную репликацию, потому что она проще и дешевле. Для active-active выбор зависит от базы, модели записи и требований к конфликтам.

Replication lag

Replication lag — задержка между записью в одном регионе и появлением этой записи в другом.

Если lag обычно 200 мс, это может быть незаметно. Если из‑за сетевой проблемы он вырос до 30 секунд, API уже может вести себя странно.

Например:

• Пользователь создаёт API key в EU.
• Через секунду запрос попадает в US.
• US region ещё не получил новый key.
• API возвращает 401.

С точки зрения пользователя это выглядит как баг: «Я только что создал ключ, почему он не работает?»

Поэтому replication lag должен быть метрикой первого класса, а не строкой в dashboard, которую никто не смотрит.

Идемпотентность

В multi-region архитектуре retries неизбежны. Клиент повторил запрос. Load balancer переключил регион. Сервис не понял, дошла ли операция до базы. Очередь доставила сообщение второй раз.

Без идемпотентности такие ситуации превращаются в дубли:

• два платежа;
• два заказа;
• две виртуальные машины;
• два email‑уведомления;
• две операции списания лимита.

Для API хорошая практика — использовать idempotency keys для небезопасных операций:

POST /ordersIdempotency-Key: 8b3f0f9d-6c5c-4b7a-9a5f-22e1b7f8e910

Если тот же запрос повторяется, система возвращает результат первой операции, а не создаёт новую.

В single-region это удобно. В multi-region — почти обязательно.

Кэширование в multi-region: ускоритель или источник сюрпризов

Кэш помогает снизить latency, уменьшить нагрузку на базу и пережить пики. Но в multi-region он добавляет ещё один слой консистентности.

Представьте: пользователь обновил настройку в EU, а в US edge cache ещё хранит старую версию. Если это цвет интерфейса — не страшно. Если это permission flag — уже опасно.

Что можно кэшировать смело

Обычно безопаснее кэшировать:

• публичный контент;
• справочники;
• read-only конфигурацию;
• статические ответы;
• агрегированную аналитику;
• данные с понятным TTL.

Что кэшировать осторожно

Осторожность нужна для:

• прав доступа;
• billing state;
• лимитов;
• статусов платежей;
• security settings;
• данных, которые пользователь ожидает увидеть сразу после изменения.

Кэш — это как заметки на стикерах. Они ускоряют работу, пока актуальны. Но если стикер устарел и никто его не снял, он начинает вредить.

Очереди и фоновые задачи

API редко живёт один. За ним стоят очереди, workers, email delivery, billing jobs, webhooks, provisioning, audit logs.

В multi-region нужно решить, как эти фоновые процессы распределены.

Вопросы, которые стоит задать:

• Очередь глобальная или региональная?
• Может ли один job выполниться дважды в разных регионах?
• Где находится scheduler?
• Что будет при failover?
• Как избежать двойной отправки webhook?
• Как workers узнают, какой регион владеет задачей?

Для active-passive можно держать workers активными только в primary region, а в standby включать при failover.

Для active-active часто лучше разделять задачи по ownership: регион обрабатывает jobs для своих tenants или своих partitions.

API contract: не скрывайте распределённость там, где она важна

Хороший API не обязан раскрывать всю внутреннюю архитектуру. Клиенту не нужно знать, в каком регионе стоит база.

Но некоторые особенности multi-region стоит отражать в контракте.

Например:

• возвращать operation id для долгих операций;
• показывать статус eventual processing;
• использовать версии ресурсов;
• поддерживать idempotency keys;
• документировать возможную задержку появления данных;
• возвращать Retry-After при перегрузке или failover;
• использовать ETag и conditional requests.

Пример:

PATCH /servers/123If-Match: "v17"

Если клиент пытается обновить старую версию объекта, API может вернуть конфликт вместо того, чтобы тихо перетереть новые данные.

409 Conflict

Это особенно полезно в active-active системах, где конкурирующие изменения реальны, а не теоретичны.

Active-passive: когда это правильный выбор

Active-passive часто недооценивают, потому что active-active звучит современнее. Но для многих API именно active-passive — зрелый и экономически разумный вариант.

Он подходит, если:

• основная цель — disaster recovery;
• допустим RTO в минуты;
• write latency из одного региона приемлема;
• команда хочет избежать multi-writer сложности;
• бюджет ограничен;
• продукт не требует постоянной глобальной локальности;
• данные сложно разделить по регионам.

Варианты standby

Active-passive бывает разным.

Pilot light

В резервном регионе развёрнут минимум: сеть, базы, базовая конфигурация, backups, возможно, часть managed services. Compute масштабируется или создаётся при аварии.

Дёшево, но RTO выше.

Warm standby

Резервный регион уже работает, но в уменьшенном размере. При failover он масштабируется.

Это хороший баланс между стоимостью и скоростью восстановления.

Hot standby

Резервный регион полностью готов принять трафик почти сразу. Он не обслуживает пользователей постоянно, но инфраструктура уже поднята.

Дороже, зато быстрее.

Выбор зависит не от вкуса архитектора, а от RTO, RPO и бюджета.

Active-active: когда игра стоит свеч

Active-active оправдан, если продукт действительно выигрывает от нескольких активных регионов.

Например:

• API обслуживает пользователей по всему миру;
• latency напрямую влияет на revenue или UX;
• downtime недопустим;
• команда готова проектировать данные под distributed system;
• есть зрелые observability и incident response;
• продукт может жить с eventual consistency в части сценариев;
• данные можно разделить по tenants или региональным partitions.

Active-active — это не награда за зрелость. Это обязательство. Система должна уметь жить в мире, где сеть задерживается, регионы видят данные не одновременно, а одинаковые запросы могут прилетать в разные места.

Если команда не готова к этим вопросам, active-active станет не страховкой, а источником новых инцидентов.

Практическая схема выбора

Можно пройтись по короткому checklist.

1. Что важнее: DR или latency?

Если главная цель — пережить падение региона, начните с active-passive.

Если главная цель — постоянно обслуживать глобальных пользователей с низкой задержкой, смотрите в сторону active-active.

2. Какие RTO и RPO реально нужны?

Не «чем меньше, тем лучше», а именно нужны.

Нулевой downtime и нулевая потеря данных стоят дорого. Иногда бизнес готов принять 10 минут восстановления, если это снижает стоимость архитектуры в разы.

3. Можно ли разделить данные?

Если данные можно естественно поделить по tenant, региону или account, active-active становится проще.

Если все пользователи постоянно пишут в одни и те же глобальные объекты, multi-writer будет болезненным.

4. Какие операции требуют strong consistency?

Составьте список критичных операций:

• списание денег;
• изменение прав;
• создание уникальных ресурсов;
• billing limits;
• security settings.

Для них можно использовать single-writer, блокировки, consensus-based хранилище или отдельный control plane.

Остальное можно проектировать более гибко.

5. Есть ли команда для эксплуатации?

Multi-region требует регулярных failover tests, мониторинга replication lag, проверки routing, runbooks и дисциплины релизов.

Если команда пока не тестирует даже single-region recovery, active-active будет слишком резким прыжком.

Observability: что мониторить в multi-region API

Обычные метрики API важны, но их недостаточно.

Нужно смотреть по регионам отдельно:

• latency p50/p95/p99;
• error rate;
• saturation;
• availability;
• request volume;
• dependency health;
• database latency;
• queue depth;
• replication lag;
• conflict rate;
• failover events;
• traffic distribution;
• cache hit ratio;
• cross-region calls.

Особенно полезны synthetic checks. Это искусственные запросы, которые регулярно проверяют ключевые сценарии: login, read, write, billing status, provisioning request.

Обычный /health говорит: «процесс жив». Synthetic check говорит: «пользовательский сценарий работает».

Разница огромная.

Failover нужно тестировать, а не обсуждать

Главная ошибка active-passive архитектуры — резервный регион существует только на диаграмме.

Вроде всё настроено: репликация, Terraform, DNS, runbook. Но когда приходит настоящий сбой, выясняется, что:

• сертификат истёк;
• переменная окружения не обновлена;
• секрет не синхронизирован;
• база отстаёт сильнее ожидаемого;
• autoscaling policy не подходит;
• DNS TTL слишком высокий;
• команда не знает, кто нажимает кнопку failover.

Failover tests нужны регулярно. Не обязательно начинать с хаос‑инжиниринга и отключения региона в полдень. Можно начать мягко:

• Проверить восстановление staging.
• Прогнать read-only трафик через резервный регион.
• Сделать controlled failover для небольшой части пользователей.
• Провести полный game day.

Multi-region без тестов — как запасной парашют, который никто никогда не раскрывал.

Deployments в нескольких регионах

Релизы в multi-region тоже требуют стратегии.

Варианты:

• одновременно выкатывать во все регионы;
• выкатывать canary в один регион;
• делать rolling deployment по регионам;
• держать backward-compatible API между версиями;
• разделять schema migration и application deploy.

Самое опасное место — база и совместимость версий.

Если Region A уже работает на новой версии API, а Region B ещё на старой, они должны понимать общие данные. Поэтому migrations лучше делать расширяющими:

• сначала добавить новое поле;
• выкатить код, который умеет работать с новым и старым форматом;
• дождаться стабилизации;
• затем удалить старое поле отдельным релизом.

Это скучно. Зато меньше шансов получить инцидент, где половина регионов пишет данные, которые другая половина не понимает.

Security и compliance

Multi-region добавляет вопросы безопасности.

Нужно контролировать:

• где хранятся персональные данные;
• какие регионы имеют доступ к ключам;
• как синхронизируются secrets;
• где пишутся audit logs;
• как работает encryption at rest и in transit;
• кто может выполнять failover;
• как ограничиваются cross-region permissions.

Особенно важно не раздавать всем регионам полный доступ ко всему «на всякий случай». Multi-region не должен превращаться в multi-risk.

Если европейские данные не должны покидать EU, это должно быть отражено не только в документации, но и в маршрутизации, storage policy, backup policy и IAM.

Типичные ошибки при проектировании multi-region API

Ошибка 1. Начать с compute, забыв про данные

Развернуть API в двух регионах относительно просто. Сделать так, чтобы данные вели себя предсказуемо, — сложно.

Сначала проектируйте data ownership и consistency model. Потом копируйте сервисы.

Ошибка 2. Называть warm standby active-active

Если второй регион не обслуживает live traffic, это не active-active. Это может быть отличный warm standby, но термины важны.

Иначе команда будет ожидать мгновенного восстановления, хотя архитектура к этому не готова.

Ошибка 3. Не учитывать write path

Многие схемы красиво описывают чтение из ближайшего региона, но молчат о записи.

А именно write path определяет сложность: latency, конфликты, блокировки, failover, RPO.

Ошибка 4. Делать eventual consistency невидимой

Если данные обновляются с задержкой, продукт должен быть к этому готов.

Лучше честно показать статус «изменение применяется», чем заставлять пользователя гадать, почему новый API key не работает в другом регионе.

Ошибка 5. Не иметь runbook

В момент сбоя никто не должен изобретать failover заново.

Runbook должен отвечать:

• кто принимает решение;
• какие сигналы считаются аварией;
• как переключить трафик;
• как проверить данные;
• как откатиться;
• как вернуть трафик обратно;
• что сообщать пользователям.

Мини‑архитектура для старта

Если команда только подходит к multi-region, хороший старт может выглядеть так:

• Один primary region обслуживает весь write traffic.
• Второй регион работает как warm standby.
• Данные реплицируются асинхронно.
• Infrastructure as Code разворачивает оба региона одинаково.
• Secrets и конфигурация синхронизируются контролируемо.
• Failover запускается через runbook или автоматизированный pipeline.
• Раз в месяц проводится failover test.
• Для критичных write‑операций используются idempotency keys.
• Monitoring показывает RTO, RPO, replication lag и health обоих регионов.

Это не самый модный вариант, зато он реалистичен. Он даёт основу, на которой потом можно строить active-active для отдельных частей API.

Например, сначала сделать active-active для read-heavy публичных endpoints, затем для stateless операций, затем для tenant‑based partitions. Не обязательно перепрыгивать пропасть одним движением.

Когда можно смешивать подходы

Архитектура не обязана быть строго active-active или active-passive для всего продукта.

Часто лучший вариант — гибрид.

Например:

• public read API работает active-active;
• billing write path остаётся single-writer;
• аналитика реплицируется eventual consistency;
• control plane работает active-passive;
• статический контент отдаётся через CDN;
• tenant data закреплены за регионами.

Такой дизайн выглядит менее эффектно на схеме, зато лучше отражает реальность. У разных частей системы разные требования, и это нормально.

Главное — явно описать, какой компонент в каком режиме работает. Иначе через полгода никто не вспомнит, почему один endpoint доступен глобально, а другой всегда ходит в primary region.

Итог

Мульти‑регион для API — это не кнопка «сделать надёжно». Это серия инженерных решений: как маршрутизировать трафик, где принимать запись, как реплицировать данные, какую консистентность обещать пользователю и сколько сложности команда готова обслуживать каждый день.

Active-passive чаще подходит как практичный и понятный путь к disaster recovery. Он снижает риск регионального сбоя, но требует честных failover tests и понятного RTO/RPO.

Active-active даёт низкую задержку и высокую доступность, но требует зрелой работы с данными: conflict resolution, idempotency, observability, routing по ownership и аккуратные API‑контракты.

Самый здоровый подход — начинать не с модного паттерна, а с требований. Какие операции критичны? Где нужна strong consistency? Где допустима eventual consistency? Сколько downtime реально стоит бизнесу? Какие данные нельзя перемещать между регионами?

Когда ответы на эти вопросы честные, архитектура становится проще. Не обязательно сразу строить идеальный глобальный control plane. Достаточно выбрать понятную модель, регулярно её проверять и развивать по мере роста продукта. В multi-region выигрывает не самая сложная схема, а та, которую команда действительно понимает, тестирует и умеет спокойно восстановить в плохой день.