DocDB архитектура показывает, как добиться 5 млн QPS и 5.5 nines без остановок. Ключ — zero-downtime data movement и строгий контроль на уровне платформы.
Проблема проявляется не сразу — до момента, когда рост нагрузки перестаёт укладываться в вертикальное масштабирование. База данных Stripe начиналась с небольшого числа MongoDB-шардов, к которым приложения подключались напрямую. По мере роста система дошла до десятков шардов, где операции обслуживания выполнялись вручную через ad hoc-скрипты. Это создало узкое место: любые изменения — от индексов до ресхардинга — стали рискованными и плохо масштабируемыми. При росте до миллионов запросов в секунду (QPS) и петабайт данных такая модель начала угрожать надёжности.
Следующий предел — физические ограничения вертикального масштабирования. Отдельные шарды выросли до десятков терабайт. Это временно решило проблему throughput, но увеличило blast radius при сбоях и усложнило операции. При требованиях уровня 5.5 nines даже кратковременная деградация становится критичной. В платёжных системах это напрямую влияет на бизнес: отказ транзакции может привести к потере клиента. Система упёрлась не только в масштаб, но и в управляемость.
Решение стало эволюционным: переход к горизонтальному масштабированию через собственную платформу данных. В центре — DocDB архитектура, построенная поверх MongoDB, но с жёстким контролем доступа и поведения. Ключевой элемент — database proxy, который стал единой точкой входа. Он решает несколько задач: connection pooling, routing, admission control и enforcement политик. Это убирает прямую связность между приложениями и шардами и позволяет централизовать управление.
Вместе с proxy появились два критичных компонента. Первый — routing metadata service, который динамически сопоставляет логические партиции с физическими шардами. Это устраняет статическую маршрутизацию и делает возможным прозрачный перенос данных. Второй — control plane, который автоматизирует жизненный цикл шардов: создание, удаление, индексацию и обслуживание. Такой сдвиг переводит систему из режима “ручного ухода за питомцами” в модель “управляемого стада”, где операции стандартизированы и автоматизированы.
Ключевая технология — zero-downtime data movement. Она позволяет выполнять горизонтальный шардинг, миграции и обновления без остановки системы. Это критично при 5 млн QPS, где даже короткий простой недопустим. Архитектурно это поддерживается через CDC pipeline: данные из oplog MongoDB передаются в Kafka и далее в S3. Это даёт возможность синхронизировать состояние между старыми и новыми шардовыми конфигурациями и поддерживать консистентность.
Реализация не сводится к добавлению компонентов — основная сложность в согласованности. При перемещении данных система должна сохранять строгую консистентность (strong consistency), что особенно важно для финансовых операций. Это ограничивает выбор стратегий миграции и требует точного контроля порядка операций. Дополнительно, multi-tenancy с квотами накладывает требования на изоляцию: один клиент не должен влиять на других, даже при пиковых нагрузках.
Отдельный слой — ограничение возможностей MongoDB. Вместо полного API платформа предоставляет минимальный набор проверенных операций. Это снижает риск неэффективных запросов, которые могут деградировать latency или вызвать каскадные сбои. Такой подход — компромисс: меньше гибкости для разработчиков, но выше предсказуемость системы.
Результат — платформа, способная обрабатывать более 5 миллионов запросов в секунду на петабайтах данных с заявленной надёжностью 5.5 nines. Также достигнута возможность выполнять масштабные изменения — шардинг, миграции, обновления — без downtime. Конкретные метрики по latency или стоимости операций не раскрываются, но архитектурные решения указывают на приоритет стабильности и управляемости над максимальной гибкостью.
DocDB архитектура демонстрирует типичный паттерн для highload-систем: отказ от прямого доступа к базе в пользу платформенного слоя, где контроль и автоматизация важнее сырой производительности. Это не универсальное решение, но для систем с высокой ценой ошибки и строгими требованиями к консистентности — прагматичный выбор.