Эталонная архитектура: высокий масштаб / высокий трафик

По мере роста трафика у защиты базы данных есть правильный порядок: сначала простые и дешёвые рычаги, затем сложные. Это дерево шаг за шагом проходит через порядок вертикальное масштабирование → реплика для чтения → шардинг, паттерны кэширования (cache-aside, write-back), буферизацию с помощью очереди + backpressure, ограничение частоты запросов (rate limiting), изоляцию базы данных с помощью bulkhead/circuit breaker и предотвращение горячих точек. Основной принцип: трудно обратимые решения, такие как шардинг, оставляйте напоследок и сначала исчерпайте дешёвые выигрыши.

Где узкое место: перегружен один экземпляр, преобладает чтение или запись, или трафик идёт всплесками?

Чтобы решить проблему масштабирования в правильном месте, сначала определите узкое место. Один экземпляр упирается в CPU/память, преобладает чтение, запись достигает предела, или внезапные пики трафика давят на базу данных? Каждый случай указывает на свой компонент.

• Один экземпляр перегружен; простые рычаги я ещё не пробовал
• Чтение очень интенсивное и растёт
• Внезапные пики трафика / всплески нагрузки давят на БД

На каком этапе масштабирования вы находитесь: вертикальное, реплики для чтения или шардинг?

У масштабирования есть правильный порядок. Вертикальное масштабирование (более мощное оборудование) — самый простой первый шаг; затем вы распределяете чтение по репликам; только когда один основной узел больше не справляется с записью, переходите к горизонтальному секционированию (шардингу). Где вы сейчас?

• Я ещё не наращивал оборудование / не исчерпал базовую настройку
• Запись помещается на одном экземпляре, но нужно распределить нагрузку чтения
• Один основной узел больше не справляется с нагрузкой записи

Как вы защитите базу данных от нагрузки: буферизацией, ограничением или изоляцией?

Масштабирование — не всегда увеличение БД; часто это защита БД от перегрузки. Вы сгладите внезапные пики записи очередью, ограничите частоту входящих запросов (rate limiting) или не дадите одной зависимости обрушить всю систему (bulkhead/circuit breaker)?

• Я хочу сгладить внезапные пики записи
• Я хочу ограничить/справедливо распределить частоту входящих запросов
• Я не хочу, чтобы одна отказавшая зависимость обрушила всю систему

Рекомендация: сначала вертикальное масштабирование и базовая настройка

Самый дешёвый и наименее рискованный шаг — вертикальное масштабирование: добавить CPU/RAM/более быстрые диски и исправить основы (индексы, пул соединений, параметры памяти). Исчерпайте эти выигрыши до сложных решений, таких как шардинг.

Рекомендация: распределение чтения с помощью реплик для чтения

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

Рекомендация: шардинг (горизонтальное секционирование) как крайняя мера

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

Рекомендация: паттерны кэширования (cache-aside + write-back)

При высоком трафике с преобладанием чтения перед БД ставится кэш в памяти (Redis), и большинство чтений обслуживается, вообще не доходя до БД. Для большого объёма записи write-back буферизует записи и сбрасывает их в БД пакетами, разгружая основной узел.

Рекомендация: буферизация с помощью очереди (backpressure)

Чтобы внезапные пики записи не били напрямую по БД, между ними ставится надёжная очередь (например, Kafka/очередь сообщений), и записи потребляются с той скоростью, которую выдерживает БД. Очередь поглощает пик; вместо синхронного отказа система работает с контролируемой задержкой (backpressure).

Рекомендация: rate limiting (ограничение частоты запросов)

Ограничивая входящие запросы по источнику (rate limiting), вы предотвращаете и злоупотребления, и захват всех ресурсов одним клиентом. Ограничение нагрузки, доходящей до БД, делает систему предсказуемой и справедливой.

Рекомендация: bulkhead + circuit breaker (изоляция)

Чтобы зависимость (например, замедляющаяся БД или внешний сервис) не обрушила всю систему, ресурсы разделяются на отсеки (bulkheads), а вызовы к постоянно отказывающей зависимости временно прекращаются (circuit breaker). Так частичный сбой не распространяется на всю систему.