Какие подходы к масштабированию баз данных ты знаешь?

Что проверяют

Понимаете ли вы, что масштабирование это набор компромиссов, а не список технологий. Интервьюер ждёт, что вы сначала измеряете, где упёрлись (чтение, запись, объём, блокировки), и только потом выбираете инструмент. Следом почти всегда идёт уточнение: «а что сломается, когда вы пошардируете» или «как жить с отставанием реплики».

Как отвечать

Идите от дешёвого к дорогому:

• выжать текущую базу: индексы под реальные запросы, EXPLAIN (ANALYZE, BUFFERS), устранение N+1, батчинг записей. Часто снимает нагрузку без новых машин;
• вертикально: больше CPU, памяти, NVMe. Упирается в цену и в потолок одной машины, но часто выигрывает год;
• пул соединений: PostgreSQL держит процесс на соединение, поэтому перед базой ставят PgBouncer в режиме transaction, а в Go ограничивают пул через SetMaxOpenConns и SetConnMaxLifetime. Тысяча простаивающих соединений кладёт базу быстрее, чем сами запросы;
• реплики на чтение: асинхронная репликация даёт лаг в десятки миллисекунд, поэтому нужен явный роутинг: критичное чтение после записи идёт в мастер, отчёты в реплику;
• кэш: Redis или локальный кэш процесса, с ответом про инвалидацию, TTL и защиту от лавины (single flight);
• партиционирование: секции по дате внутри одной базы, старые отрезаются через DETACH PARTITION мгновенно;
• шардирование: выбор ключа, hash или range, процедура ре-шардинга, Citus или Vitess вместо самописного роутера.

Отдельно скажите, что теряется при шардировании: кросс-шардовые JOIN и агрегаты, глобальные уникальные индексы (отсюда UUIDv7 вместо serial), транзакции на несколько шардов, которые заменяются сагами и идемпотентными обработчиками. Хорошо звучит и разделение нагрузок: OLTP остаётся в PostgreSQL, аналитика уезжает в ClickHouse через CDC.

Где спотыкаются

Называют шардирование первым пунктом. Это самый дорогой шаг, и на большинстве нагрузок до него не доходит.

Считают реплику решением проблемы записи. Реплика разгружает чтение, а мастер пишет ровно столько же, плюс тратится на саму репликацию.

Забывают про лаг и получают классический баг: пользователь сохранил профиль, редирект прочитал реплику, на экране старые данные.