Ответ на вопрос.

История вопроса

Компании, расширяющиеся на глобальном уровне, сталкиваются со строгими законами о местонахождении данных, такими как GDPR и CCPA. Традиционные монолитные базы данных централизуют данные в одном регионе, нарушая суверенитет или вызывая высокую задержку. Ранние распределенные системы использовали активную-пассивную репликацию, но это создает единую точку отказа и проблемы с задержкой записи. Современные архитектуры должны поддерживать многопользовательские регионы, где пользователи в ЕС, США и АПЕК могут записывать данные локально, соблюдая ограничения местоположения данных.

Проблема

Основной проблемой являются компромиссы теоремы CAP. Нельзя одновременно сохранять сильную согласованность между регионами с низкой задержкой и устойчивостью к разделениям. Кроме того, отношения внешних ключей, охватывающие регионы, становятся невозможными, когда данные не могут пересекать границы. Транзакции между регионами рискуют нарушить соблюдение норм, если PII просочится во время координации. Поддержка чтений менее 100 мс требует кэширования, но инвалидация кэша через суверенные границы является сложной задачей.

Решение

Реализуйте Клеточную Архитектуру, используя нативное геораспределение баз данных (например, CockroachDB или Google Cloud Spanner). Разделите таблицы по колонне region, чтобы гарантировать, что PII никогда не покидает свою физическую ячейку. Используйте Change Data Capture (CDC) через Apache Kafka для репликации только не чувствительных метаданных по всему миру. Для транзакций между регионами реализуйте Шаблон Саги с локальными компенсациями, чтобы избежать распределенных блокировок. Разверните кластеры Redis на границе с использованием шаблона Cache-Aside для задач с высокой нагрузкой на чтение, используя инвалидацию на основе TTL, чтобы избежать координации кэша между регионами.

Ситуация из жизни

Контекст

Глобальному процессору платежей понадобилось запуститься в Германии и Сингапуре, сохраняя свой центрон данных в США. Регуляторные требования обязывали оставить историю транзакций пользователей ЕС физически в Франкфурте, в то время как данные АПЕК должны были оставаться в Сингапуре. Тем не менее, трансакции через границы требовали списания средств с счетов в США и кредитования счетов в ЕС в рамках одной логической транзакции, обеспечивая при этом поиск баланса менее чем 100 мс.

Решение 1: Централизованная база данных с региональными читаемыми репликами

Этот подход будет размещать основную базу данных в US-East с читаемыми репликами в ЕС и АПЕК, предлагая простую модель согласованности и четкие гарантии ACID без сложной синхронизации. Однако это нарушает законы о суверенитете данных, поскольку записи направляются в US-East, потенциально сохраняя EU PII на США, в то время как записи из Сингапура могут привести к задержке в более 200 мс, что нарушает требования пользователя. Архитектура также создает единую точку отказа в US-East, делая ее неприемлемой для глобальной платформы платежей, требующей региональной автономии.

Решение 2: Полностью изолированные региональные силосы с ночным ETL

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

Решение 3: Геораспределенная база данных с оркестрацией Саги

Эта стратегия развертывает CockroachDB с геораспределенными таблицами, используя отображение partition_key на домашние регионы пользователей, для управления трансакциями между регионами как локальными транзакциями с компенсационными действиями. Этот дизайн обеспечивает нативное местоположение данных через ограничения раздела, при этом достигая локальных чтений менее 50 мс за счет прокси, зафиксированных за региональными узлами, хотя это вводит операционную сложность, требующую экспертизы в распределенном SQL. Решение обрабатывает конечную согласованность для метаданных между регионами через потоки Kafka CDC и управляет временной несогласованностью во время выполнения саги с помощью видимости ожидания состояния на основе TTL.

Выбранный подход

Команда выбрала Решение 3, потому что оно уникально удовлетворяло обе меры соблюдения и задержки, не жертвуя семантикой транзакций и не требуя разрушительных миграций данных. Они настроили CockroachDB REGIONAL BY ROW таблицы, фиксируя строки ЕС за узлами Франкфурта, развернули кластер Redis в местах перехода с 5-секундным TTL для кэширования метаданных и реализовали саги Temporal для управления трансакциями между регионами с автоматическими компенсациями в случае ошибки.

Результат

Система успешно прошла аудит GDPR с нулевым утечкой PII через границы, обрабатывая 50,000 ежедневных трансакций между регионами с 99-м процентилем задержки чтения 45 мс. Команды поддержки клиентов могли запрашивать состояния саги через API конечные точки, чтобы разрешать временные несогласованности во время региональных перебоев. Архитектура теперь поддерживает расширение на новые рынки, просто добавляя новые ячейки в кластер CockroachDB без изменений приложения.

Что кандидаты часто упускают

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

Вы не можете применить ограничения внешнего ключа на уровне базы данных через регионы, когда данные не могут физически покинуть свою зону. Реализуйте целостность ссылки на уровне приложений, используя ссылки UUID и асинхронную проверку через Outbox Pattern, публикуя в Kafka; потребители проверяют ссылки и публикуют подтверждения, выявляя сирот после тайм-аутов. Это жертвует немедленной согласованностью ради соблюдения, но обеспечивает конечную целостность без миграции данных, используя компенсацию Saga для отката транзакций, ссылающихся на недействительные внешние ключи.

Что происходит с транзакциями в процессе выполнения, когда регион выходит из строя во время кросс-региональной саги?

Шаблоны Saga автоматически не обрабатывают сбои; вы должны разрабатывать с учетом идемпотентности, используя ключи идемпотентности, хранящиеся в местном Redis или Etcd каждого региона, чтобы предотвратить дублирование обработки во время повторных попыток. Если Регион B выходит из строя во время операции кредита, тайм-аут оркестратора инициирует компенсационные транзакции в Регионе A для возврата списанных сумм, используя Advisory Locks PostgreSQL или Distributed Locks ZooKeeper для предотвращения конкурентных условий во время переключения по сбоям оркестратора. Система должна предоставлять состояния ожидающих транзакций через API конечные точки для вмешательства поддержки клиентов, обеспечивая, чтобы состояния частичных сбоев оставались запрашиваемыми и решаемыми без повреждения данных.

Как вы выполняете миграции схемы без простоя через геораспределенные ячейки с разными окнами обслуживания?

Используйте шаблон Expand-Contract в сочетании с Feature Flags, управляемыми LaunchDarkly, сначала развернув добавочные изменения DDL (новые колонки, таблицы) по всем регионам в их соответствующих окнах с использованием Flyway или Liquibase с учетом обратной совместимости приложений. Мигрируйте данные асинхронно с использованием Debezium CDC трубопроводов, затем включите новые кодовые пути через флаги функций только после подтверждения распространения схемы через проверки состояния, обеспечивая, чтобы ни один регион не обслуживал устаревшие данные. Никогда не выполняйте разрушительные DDL (удаление колонок), пока все регионы не подтвердят завершение миграции, используя развертывания Blue-Green в каждой ячейке для мгновенного отката в случае превышения порогов задержки репликации.