Базы данных

Экспресс-шпаргалка 20/20

1. SQL выбирают для строгих связей и транзакций, NoSQL для гибкой схемы и отдельных сценариев масштабирования.
2. INNER JOIN возвращает только совпадения, LEFT JOIN оставляет все строки левой таблицы.
3. Индекс ускоряет поиск/сортировку, но требует памяти и обновляется на insert/update/delete.
4. Запись замедляется, потому что БД должна модифицировать не только таблицу, но и все затронутые индексы.
5. N+1 возникает при серии мелких запросов вместо батча; лечится joins/eager loading/batching.
6. Транзакция дает атомарность, уровни изоляции контролируют аномалии конкурентного чтения/записи.
7. ACID дает надежность, но в распределенных системах часто появляются компромиссы между latency и консистентностью.
8. Для больших таблиц пагинацию строят по индексируемому ORDER BY и стабильному ключу.
9. Offset прост, но деградирует на больших смещениях; cursor быстрее и стабильнее при большом объеме.
10. План запроса (EXPLAIN/ANALYZE) показывает scan/join strategy, cost и узкие места.
11. One-to-many обычно через FK, many-to-many через junction table с индексами по обоим ключам.
12. Нормализация снижает дубли, денормализация ускоряет чтение ценой сложности обновлений.
13. Optimistic locking через version/updated_at защищает от lost update без жестких блокировок.
14. Zero-downtime миграции делают поэтапно: additive changes -> dual-read/write -> cleanup.
15. Уникальные ограничения и idempotency key защищают от дублей при ретраях и сетевых повторах.
16. Кэш без стратегии инвалидации быстро становится источником stale-данных и расхождений.
17. Read-replica разгружает чтение, но нужно учитывать replication lag и eventual consistency.
18. Мониторинг БД: p95 latency, slow queries, lock waits, CPU/IO saturation, pool usage.
19. ORM хорош для скорости разработки, raw SQL нужен для сложных и perf-критичных запросов.
20. JSON в SQL удобен для гибкости схемы, но усложняет индексацию, валидацию и оптимизацию запросов.

1. Когда выбрать SQL, а когда NoSQL?

Теги: database, sql Сложность: Middle/Senior

Короткий ответ

SQL предпочтителен для строгих связей и транзакций, NoSQL - для гибких схем и некоторых сценариев горизонтального масштаба.

Что сказать на интервью (30-60 секунд)

1. Где это применяется: Критично для производительности API, целостности данных и масштабируемости продукта.
2. Главный риск: Оптимизация без EXPLAIN и реальных метрик часто маскирует проблему и ухудшает write/read баланс.
3. Как проверяете решение: Сравниваю EXPLAIN ANALYZE до/после и смотрю p95 latency на рабочем запросе.

Мини-пример

EXPLAIN ANALYZE
SELECT * FROM orders
WHERE user_id = $1
ORDER BY created_at DESC
LIMIT 20;

Углубление (2-3 минуты)

1. Свяжите тему "Когда выбрать SQL, а когда NoSQL?" с одним production-сценарием и объясните, почему она влияет на результат.
2. Добавьте проверку через EXPLAIN/план выполнения или эквивалентную метрику.
3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки

1. Добавляют индексы без анализа плана запроса и профиля нагрузки.
2. Лечат N+1 точечно, не исправляя модель доступа к данным.
3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы

1. Как изменится план запроса после вашей правки?
2. Когда стоит перейти с offset на cursor pagination?
3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить

1. Транзакции, изоляцию и риск блокировок.
2. Индексы, план запроса и N+1/батчинг.
3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта

1. Обучение: Базы данных
2. Обучение: Node.js
3. Карта подготовки: Базы данных

2. Как объяснить разницу между INNER JOIN и LEFT JOIN?

Теги: database, sql Сложность: Middle/Senior

Короткий ответ

INNER JOIN дает пересечение, LEFT JOIN оставляет все строки левой таблицы.

Что сказать на интервью (30-60 секунд)

1. Где это применяется: Критично для производительности API, целостности данных и масштабируемости продукта.
2. Главный риск: Оптимизация без EXPLAIN и реальных метрик часто маскирует проблему и ухудшает write/read баланс.
3. Как проверяете решение: Проверяю план выполнения и селективность индексов, затем гоняю сценарий записи под нагрузкой.

Мини-пример

SELECT u.id, o.id AS order_id
FROM users u
LEFT JOIN orders o ON o.user_id = u.id;

Углубление (2-3 минуты)

1. Свяжите тему "Как объяснить разницу между INNER JOIN и LEFT JOIN?" с одним production-сценарием и объясните, почему она влияет на результат.
2. Добавьте проверку через EXPLAIN/план выполнения или эквивалентную метрику.
3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки

1. Не учитывают write-cost и блокировки при оптимизации чтения.
2. Лечат N+1 точечно, не исправляя модель доступа к данным.
3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы

1. Как решение повлияет на write path и блокировки?
2. Когда стоит перейти с offset на cursor pagination?
3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить

1. Индексы, план запроса и N+1/батчинг.
2. Стратегию кэширования и инвалидации.
3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта

1. Обучение: Базы данных
2. Обучение: Node.js
3. Карта подготовки: Базы данных

3. Что такое индекс и как он влияет на запросы?

Теги: database, sql Сложность: Middle/Senior

Короткий ответ

Индекс ускоряет поиск/фильтрацию/сортировку за счет дополнительной структуры данных.

Что сказать на интервью (30-60 секунд)

1. Где это применяется: Критично для производительности API, целостности данных и масштабируемости продукта.
2. Главный риск: Избыточная индексация ухудшает write path и увеличивает стоимость хранения.
3. Как проверяете решение: Сравниваю EXPLAIN ANALYZE до/после и смотрю p95 latency на рабочем запросе.

Мини-пример

CREATE INDEX idx_orders_user_id ON orders(user_id);

Углубление (2-3 минуты)

1. Свяжите тему "Что такое индекс и как он влияет на запросы?" с одним production-сценарием и объясните, почему она влияет на результат.
2. Добавьте проверку через EXPLAIN/план выполнения или эквивалентную метрику.
3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки

1. Добавляют индексы без анализа плана запроса и профиля нагрузки.
2. Не учитывают write-cost и блокировки при оптимизации чтения.
3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы

1. Как решение повлияет на write path и блокировки?
2. Как изменится план запроса после вашей правки?
3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить

1. Стратегию кэширования и инвалидации.
2. Транзакции, изоляцию и риск блокировок.
3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта

1. Обучение: Базы данных
2. Обучение: Node.js
3. Карта подготовки: Базы данных

4. Почему индекс может замедлить запись?

Теги: database, sql Сложность: Middle/Senior

Короткий ответ

Индекс может замедлить запись, потому что его тоже нужно обновлять при insert/update/delete.

Что сказать на интервью (30-60 секунд)

1. Где это применяется: Критично для производительности API, целостности данных и масштабируемости продукта.
2. Главный риск: Избыточная индексация ухудшает write path и увеличивает стоимость хранения.
3. Как проверяете решение: Сравниваю EXPLAIN ANALYZE до/после и смотрю p95 latency на рабочем запросе.

Мини-пример

CREATE INDEX idx_orders_user_id ON orders(user_id);

Углубление (2-3 минуты)

1. Свяжите тему "Почему индекс может замедлить запись?" с одним production-сценарием и объясните, почему она влияет на результат.
2. Сравните baseline и after на реалистичном наборе данных.
3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки

1. Не учитывают write-cost и блокировки при оптимизации чтения.
2. Лечат N+1 точечно, не исправляя модель доступа к данным.
3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы

1. Когда стоит перейти с offset на cursor pagination?
2. Как изменится план запроса после вашей правки?
3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить

1. Транзакции, изоляцию и риск блокировок.
2. Стратегию кэширования и инвалидации.
3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта

1. Обучение: Базы данных
2. Обучение: Node.js
3. Карта подготовки: Базы данных

5. Что такое N+1 проблема и как ее избежать?

Теги: database, sql Сложность: Middle/Senior

Короткий ответ

N+1 - это серия мелких запросов вместо батча; обычно лечится eager loading и joins.

Что сказать на интервью (30-60 секунд)

1. Где это применяется: Критично для производительности API, целостности данных и масштабируемости продукта.
2. Главный риск: Оптимизация без EXPLAIN и реальных метрик часто маскирует проблему и ухудшает write/read баланс.
3. Как проверяете решение: Проверяю план выполнения и селективность индексов, затем гоняю сценарий записи под нагрузкой.

Мини-пример

EXPLAIN ANALYZE
SELECT * FROM orders
WHERE user_id = $1
ORDER BY created_at DESC
LIMIT 20;

Углубление (2-3 минуты)

1. Свяжите тему "Что такое N+1 проблема и как ее избежать?" с одним production-сценарием и объясните, почему она влияет на результат.
2. Поясните, как тема влияет на read/write путь и стоимость операций.
3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки

1. Добавляют индексы без анализа плана запроса и профиля нагрузки.
2. Лечат N+1 точечно, не исправляя модель доступа к данным.
3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы

1. Как решение повлияет на write path и блокировки?
2. Как изменится план запроса после вашей правки?
3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить

1. Стратегию кэширования и инвалидации.
2. Транзакции, изоляцию и риск блокировок.
3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта

1. Обучение: Базы данных
2. Обучение: Node.js
3. Карта подготовки: Базы данных

6. Как работает транзакция и зачем уровни изоляции?

Теги: database, sql Сложность: Middle/Senior

Короткий ответ

Транзакция объединяет операции в атомарный блок, уровни изоляции регулируют конкуренцию.

Что сказать на интервью (30-60 секунд)

1. Где это применяется: Критично для производительности API, целостности данных и масштабируемости продукта.
2. Главный риск: Оптимизация без EXPLAIN и реальных метрик часто маскирует проблему и ухудшает write/read баланс.
3. Как проверяете решение: Сравниваю EXPLAIN ANALYZE до/после и смотрю p95 latency на рабочем запросе.

Мини-пример

BEGIN;
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
UPDATE accounts SET balance = balance + 100 WHERE id = 2;
COMMIT;

Углубление (2-3 минуты)

1. Свяжите тему "Как работает транзакция и зачем уровни изоляции?" с одним production-сценарием и объясните, почему она влияет на результат.
2. Сравните baseline и after на реалистичном наборе данных.
3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки

1. Лечат N+1 точечно, не исправляя модель доступа к данным.
2. Не учитывают write-cost и блокировки при оптимизации чтения.
3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы

1. Как изменится план запроса после вашей правки?
2. Как решение повлияет на write path и блокировки?
3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить

1. Стратегию кэширования и инвалидации.
2. Индексы, план запроса и N+1/батчинг.
3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта

1. Обучение: Базы данных
2. Обучение: Node.js
3. Карта подготовки: Базы данных

7. Что такое ACID и где нужны компромиссы?

Теги: database, sql Сложность: Middle/Senior

Короткий ответ

ACID задает надежность и консистентность, но в distributed-системах возможны компромиссы.

Что сказать на интервью (30-60 секунд)

1. Где это применяется: Критично для производительности API, целостности данных и масштабируемости продукта.
2. Главный риск: Оптимизация без EXPLAIN и реальных метрик часто маскирует проблему и ухудшает write/read баланс.
3. Как проверяете решение: Сравниваю EXPLAIN ANALYZE до/после и смотрю p95 latency на рабочем запросе.

Мини-пример

EXPLAIN ANALYZE
SELECT * FROM orders
WHERE user_id = $1
ORDER BY created_at DESC
LIMIT 20;

Углубление (2-3 минуты)

1. Свяжите тему "Что такое ACID и где нужны компромиссы?" с одним production-сценарием и объясните, почему она влияет на результат.
2. Поясните, как тема влияет на read/write путь и стоимость операций.
3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки

1. Добавляют индексы без анализа плана запроса и профиля нагрузки.
2. Лечат N+1 точечно, не исправляя модель доступа к данным.
3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы

1. Когда стоит перейти с offset на cursor pagination?
2. Как решение повлияет на write path и блокировки?
3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить

1. Индексы, план запроса и N+1/батчинг.
2. Стратегию кэширования и инвалидации.
3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта

1. Обучение: Базы данных
2. Обучение: Node.js
3. Карта подготовки: Базы данных

8. Как проектировать пагинацию для больших таблиц?

Теги: database, sql Сложность: Middle/Senior

Короткий ответ

Пагинацию больших таблиц проектируют с индексируемым order-by и предсказуемой стабильностью.

Что сказать на интервью (30-60 секунд)

1. Где это применяется: Критично для производительности API, целостности данных и масштабируемости продукта.
2. Главный риск: Оптимизация без EXPLAIN и реальных метрик часто маскирует проблему и ухудшает write/read баланс.
3. Как проверяете решение: Фиксирую query-budget, прогоняю regression-набор и контролирую блокировки/конкуренцию транзакций.

Мини-пример

EXPLAIN ANALYZE
SELECT * FROM orders
WHERE user_id = $1
ORDER BY created_at DESC
LIMIT 20;

Углубление (2-3 минуты)

1. Свяжите тему "Как проектировать пагинацию для больших таблиц?" с одним production-сценарием и объясните, почему она влияет на результат.
2. Сравните baseline и after на реалистичном наборе данных.
3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки

1. Не учитывают write-cost и блокировки при оптимизации чтения.
2. Лечат N+1 точечно, не исправляя модель доступа к данным.
3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы

1. Как решение повлияет на write path и блокировки?
2. Как изменится план запроса после вашей правки?
3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить

1. Стратегию кэширования и инвалидации.
2. Транзакции, изоляцию и риск блокировок.
3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта

1. Обучение: Базы данных
2. Обучение: Node.js
3. Карта подготовки: Базы данных

9. Offset pagination vs cursor pagination?

Теги: database, sql Сложность: Middle/Senior

Короткий ответ

Offset pagination проще, cursor pagination устойчивее на больших наборах данных.

Что сказать на интервью (30-60 секунд)

1. Где это применяется: Критично для производительности API, целостности данных и масштабируемости продукта.
2. Главный риск: Оптимизация без EXPLAIN и реальных метрик часто маскирует проблему и ухудшает write/read баланс.
3. Как проверяете решение: Проверяю план выполнения и селективность индексов, затем гоняю сценарий записи под нагрузкой.

Мини-пример

SELECT * FROM posts
WHERE id > $1
ORDER BY id
LIMIT 20;

Углубление (2-3 минуты)

1. Свяжите тему "Offset pagination vs cursor pagination?" с одним production-сценарием и объясните, почему она влияет на результат.
2. Добавьте проверку через EXPLAIN/план выполнения или эквивалентную метрику.
3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки

1. Не учитывают write-cost и блокировки при оптимизации чтения.
2. Добавляют индексы без анализа плана запроса и профиля нагрузки.
3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы

1. Когда стоит перейти с offset на cursor pagination?
2. Как изменится план запроса после вашей правки?
3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить

1. Стратегию кэширования и инвалидации.
2. Транзакции, изоляцию и риск блокировок.
3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта

1. Обучение: Базы данных
2. Обучение: Node.js
3. Карта подготовки: Базы данных

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

Теги: database, sql Сложность: Middle/Senior

Короткий ответ

План выполнения показывает реальный путь выполнения запроса и узкие места.

Что сказать на интервью (30-60 секунд)

1. Где это применяется: Критично для производительности API, целостности данных и масштабируемости продукта.
2. Главный риск: Оптимизация без EXPLAIN и реальных метрик часто маскирует проблему и ухудшает write/read баланс.
3. Как проверяете решение: Фиксирую query-budget, прогоняю regression-набор и контролирую блокировки/конкуренцию транзакций.

Мини-пример

EXPLAIN ANALYZE
SELECT * FROM orders
WHERE user_id = $1
ORDER BY created_at DESC
LIMIT 20;

Углубление (2-3 минуты)

1. Свяжите тему "Как читать план выполнения запроса?" с одним production-сценарием и объясните, почему она влияет на результат.
2. Добавьте проверку через EXPLAIN/план выполнения или эквивалентную метрику.
3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки

1. Добавляют индексы без анализа плана запроса и профиля нагрузки.
2. Лечат N+1 точечно, не исправляя модель доступа к данным.
3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы

1. Как решение повлияет на write path и блокировки?
2. Как изменится план запроса после вашей правки?
3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить

1. Стратегию кэширования и инвалидации.
2. Транзакции, изоляцию и риск блокировок.
3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта

1. Обучение: Базы данных
2. Обучение: Node.js
3. Карта подготовки: Базы данных

11. Как проектировать связи one-to-many и many-to-many?

Теги: database, sql Сложность: Middle/Senior

Короткий ответ

Связи one-to-many/many-to-many строят через FK и join-таблицы.

Что сказать на интервью (30-60 секунд)

1. Где это применяется: Критично для производительности API, целостности данных и масштабируемости продукта.
2. Главный риск: Оптимизация без EXPLAIN и реальных метрик часто маскирует проблему и ухудшает write/read баланс.
3. Как проверяете решение: Проверяю план выполнения и селективность индексов, затем гоняю сценарий записи под нагрузкой.

Мини-пример

EXPLAIN ANALYZE
SELECT * FROM orders
WHERE user_id = $1
ORDER BY created_at DESC
LIMIT 20;

Углубление (2-3 минуты)

1. Свяжите тему "Как проектировать связи one-to-many и many-to-many?" с одним production-сценарием и объясните, почему она влияет на результат.
2. Добавьте проверку через EXPLAIN/план выполнения или эквивалентную метрику.
3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки

1. Добавляют индексы без анализа плана запроса и профиля нагрузки.
2. Лечат N+1 точечно, не исправляя модель доступа к данным.
3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы

1. Как решение повлияет на write path и блокировки?
2. Как изменится план запроса после вашей правки?
3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить

1. Стратегию кэширования и инвалидации.
2. Индексы, план запроса и N+1/батчинг.
3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта

1. Обучение: Базы данных
2. Обучение: Node.js
3. Карта подготовки: Базы данных

12. Как выбирать между денормализацией и нормализацией?

Теги: database, sql Сложность: Middle/Senior

Короткий ответ

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

Что сказать на интервью (30-60 секунд)

1. Где это применяется: Критично для производительности API, целостности данных и масштабируемости продукта.
2. Главный риск: Оптимизация без EXPLAIN и реальных метрик часто маскирует проблему и ухудшает write/read баланс.
3. Как проверяете решение: Проверяю план выполнения и селективность индексов, затем гоняю сценарий записи под нагрузкой.

Мини-пример

EXPLAIN ANALYZE
SELECT * FROM orders
WHERE user_id = $1
ORDER BY created_at DESC
LIMIT 20;

Углубление (2-3 минуты)

1. Свяжите тему "Как выбирать между денормализацией и нормализацией?" с одним production-сценарием и объясните, почему она влияет на результат.
2. Сравните baseline и after на реалистичном наборе данных.
3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки

1. Не учитывают write-cost и блокировки при оптимизации чтения.
2. Лечат N+1 точечно, не исправляя модель доступа к данным.
3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы

1. Как решение повлияет на write path и блокировки?
2. Как изменится план запроса после вашей правки?
3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить

1. Стратегию кэширования и инвалидации.
2. Транзакции, изоляцию и риск блокировок.
3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта

1. Обучение: Базы данных
2. Обучение: Node.js
3. Карта подготовки: Базы данных

13. Что такое optimistic locking и где его применять?

Теги: database, sql Сложность: Middle/Senior

Короткий ответ

Optimistic locking защищает от lost updates через версионирование записи.

Что сказать на интервью (30-60 секунд)

1. Где это применяется: Критично для производительности API, целостности данных и масштабируемости продукта.
2. Главный риск: Оптимизация без EXPLAIN и реальных метрик часто маскирует проблему и ухудшает write/read баланс.
3. Как проверяете решение: Сравниваю EXPLAIN ANALYZE до/после и смотрю p95 latency на рабочем запросе.

Мини-пример

EXPLAIN ANALYZE
SELECT * FROM orders
WHERE user_id = $1
ORDER BY created_at DESC
LIMIT 20;

Углубление (2-3 минуты)

1. Свяжите тему "Что такое optimistic locking и где его применять?" с одним production-сценарием и объясните, почему она влияет на результат.
2. Сравните baseline и after на реалистичном наборе данных.
3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки

1. Не учитывают write-cost и блокировки при оптимизации чтения.
2. Лечат N+1 точечно, не исправляя модель доступа к данным.
3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы

1. Как решение повлияет на write path и блокировки?
2. Когда стоит перейти с offset на cursor pagination?
3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить

1. Индексы, план запроса и N+1/батчинг.
2. Стратегию кэширования и инвалидации.
3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта

1. Обучение: Базы данных
2. Обучение: Node.js
3. Карта подготовки: Базы данных

14. Как организовать миграции схемы без простоев?

Теги: database, sql Сложность: Middle/Senior

Короткий ответ

Zero-downtime миграции требуют обратной совместимости и поэтапного релиза.

Что сказать на интервью (30-60 секунд)

1. Где это применяется: Критично для производительности API, целостности данных и масштабируемости продукта.
2. Главный риск: Big-bang миграции без rollback-плана часто приводят к длительным инцидентам.
3. Как проверяете решение: Проверяю план выполнения и селективность индексов, затем гоняю сценарий записи под нагрузкой.

Мини-пример

EXPLAIN ANALYZE
SELECT * FROM orders
WHERE user_id = $1
ORDER BY created_at DESC
LIMIT 20;

Углубление (2-3 минуты)

1. Свяжите тему "Как организовать миграции схемы без простоев?" с одним production-сценарием и объясните, почему она влияет на результат.
2. Поясните, как тема влияет на read/write путь и стоимость операций.
3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки

1. Лечат N+1 точечно, не исправляя модель доступа к данным.
2. Не учитывают write-cost и блокировки при оптимизации чтения.
3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы

1. Когда стоит перейти с offset на cursor pagination?
2. Как изменится план запроса после вашей правки?
3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить

1. Стратегию кэширования и инвалидации.
2. Транзакции, изоляцию и риск блокировок.
3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта

1. Обучение: Базы данных
2. Обучение: Node.js
3. Карта подготовки: Базы данных

15. Как проектировать уникальные ограничения и idempotency?

Теги: database, sql Сложность: Middle/Senior

Короткий ответ

Уникальные ограничения и idempotency-ключи защищают от дублей при повторах запросов.

Что сказать на интервью (30-60 секунд)

1. Где это применяется: Критично для производительности API, целостности данных и масштабируемости продукта.
2. Главный риск: Оптимизация без EXPLAIN и реальных метрик часто маскирует проблему и ухудшает write/read баланс.
3. Как проверяете решение: Фиксирую query-budget, прогоняю regression-набор и контролирую блокировки/конкуренцию транзакций.

Мини-пример

EXPLAIN ANALYZE
SELECT * FROM orders
WHERE user_id = $1
ORDER BY created_at DESC
LIMIT 20;

Углубление (2-3 минуты)

1. Свяжите тему "Как проектировать уникальные ограничения и idempotency?" с одним production-сценарием и объясните, почему она влияет на результат.
2. Поясните, как тема влияет на read/write путь и стоимость операций.
3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки

1. Добавляют индексы без анализа плана запроса и профиля нагрузки.
2. Не учитывают write-cost и блокировки при оптимизации чтения.
3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы

1. Как изменится план запроса после вашей правки?
2. Как решение повлияет на write path и блокировки?
3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить

1. Стратегию кэширования и инвалидации.
2. Индексы, план запроса и N+1/батчинг.
3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта

1. Обучение: Базы данных
2. Обучение: Node.js
3. Карта подготовки: Базы данных

16. Как кешировать данные и не ломать консистентность?

Теги: database, sql Сложность: Middle/Senior

Короткий ответ

Кэш улучшает чтение, но требует стратегии инвалидации и контроля stale данных.

Что сказать на интервью (30-60 секунд)

1. Где это применяется: Критично для производительности API, целостности данных и масштабируемости продукта.
2. Главный риск: Оптимизация без EXPLAIN и реальных метрик часто маскирует проблему и ухудшает write/read баланс.
3. Как проверяете решение: Фиксирую query-budget, прогоняю regression-набор и контролирую блокировки/конкуренцию транзакций.

Мини-пример

EXPLAIN ANALYZE
SELECT * FROM orders
WHERE user_id = $1
ORDER BY created_at DESC
LIMIT 20;

Углубление (2-3 минуты)

1. Свяжите тему "Как кешировать данные и не ломать консистентность?" с одним production-сценарием и объясните, почему она влияет на результат.
2. Поясните, как тема влияет на read/write путь и стоимость операций.
3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки

1. Добавляют индексы без анализа плана запроса и профиля нагрузки.
2. Лечат N+1 точечно, не исправляя модель доступа к данным.
3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы

1. Когда стоит перейти с offset на cursor pagination?
2. Как изменится план запроса после вашей правки?
3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить

1. Транзакции, изоляцию и риск блокировок.
2. Стратегию кэширования и инвалидации.
3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта

1. Обучение: Базы данных
2. Обучение: Node.js
3. Карта подготовки: Базы данных

17. Когда нужен read-replica и как с ним работать?

Теги: database, sql Сложность: Middle/Senior

Короткий ответ

Read replicas масштабируют чтение, но нужно учитывать replication lag.

Что сказать на интервью (30-60 секунд)

1. Где это применяется: Критично для производительности API, целостности данных и масштабируемости продукта.
2. Главный риск: Оптимизация без EXPLAIN и реальных метрик часто маскирует проблему и ухудшает write/read баланс.
3. Как проверяете решение: Фиксирую query-budget, прогоняю regression-набор и контролирую блокировки/конкуренцию транзакций.

Мини-пример

EXPLAIN ANALYZE
SELECT * FROM orders
WHERE user_id = $1
ORDER BY created_at DESC
LIMIT 20;

Углубление (2-3 минуты)

1. Свяжите тему "Когда нужен read-replica и как с ним работать?" с одним production-сценарием и объясните, почему она влияет на результат.
2. Поясните, как тема влияет на read/write путь и стоимость операций.
3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки

1. Лечат N+1 точечно, не исправляя модель доступа к данным.
2. Не учитывают write-cost и блокировки при оптимизации чтения.
3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы

1. Как изменится план запроса после вашей правки?
2. Как решение повлияет на write path и блокировки?
3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить

1. Транзакции, изоляцию и риск блокировок.
2. Индексы, план запроса и N+1/батчинг.
3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта

1. Обучение: Базы данных
2. Обучение: Node.js
3. Карта подготовки: Базы данных

18. Как мониторить базу и выявлять деградации?

Теги: database, sql Сложность: Middle/Senior

Короткий ответ

Мониторинг БД: slow queries, lock waits, p95 latency, saturation пула соединений.

Что сказать на интервью (30-60 секунд)

1. Где это применяется: Критично для производительности API, целостности данных и масштабируемости продукта.
2. Главный риск: Оптимизация без EXPLAIN и реальных метрик часто маскирует проблему и ухудшает write/read баланс.
3. Как проверяете решение: Сравниваю EXPLAIN ANALYZE до/после и смотрю p95 latency на рабочем запросе.

Мини-пример

EXPLAIN ANALYZE
SELECT * FROM orders
WHERE user_id = $1
ORDER BY created_at DESC
LIMIT 20;

Углубление (2-3 минуты)

1. Свяжите тему "Как мониторить базу и выявлять деградации?" с одним production-сценарием и объясните, почему она влияет на результат.
2. Поясните, как тема влияет на read/write путь и стоимость операций.
3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки

1. Добавляют индексы без анализа плана запроса и профиля нагрузки.
2. Не учитывают write-cost и блокировки при оптимизации чтения.
3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы

1. Когда стоит перейти с offset на cursor pagination?
2. Как изменится план запроса после вашей правки?
3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить

1. Транзакции, изоляцию и риск блокировок.
2. Стратегию кэширования и инвалидации.
3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта

1. Обучение: Базы данных
2. Обучение: Node.js
3. Карта подготовки: Базы данных

19. Какие риски у ORM и когда писать raw SQL?

Теги: database, sql Сложность: Middle/Senior

Короткий ответ

ORM ускоряет разработку, но для сложных запросов часто нужен raw SQL.

Что сказать на интервью (30-60 секунд)

1. Где это применяется: Критично для производительности API, целостности данных и масштабируемости продукта.
2. Главный риск: Оптимизация без EXPLAIN и реальных метрик часто маскирует проблему и ухудшает write/read баланс.
3. Как проверяете решение: Проверяю план выполнения и селективность индексов, затем гоняю сценарий записи под нагрузкой.

Мини-пример

EXPLAIN ANALYZE
SELECT * FROM orders
WHERE user_id = $1
ORDER BY created_at DESC
LIMIT 20;

Углубление (2-3 минуты)

1. Свяжите тему "Какие риски у ORM и когда писать raw SQL?" с одним production-сценарием и объясните, почему она влияет на результат.
2. Добавьте проверку через EXPLAIN/план выполнения или эквивалентную метрику.
3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки

1. Лечат N+1 точечно, не исправляя модель доступа к данным.
2. Добавляют индексы без анализа плана запроса и профиля нагрузки.
3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы

1. Как решение повлияет на write path и блокировки?
2. Как изменится план запроса после вашей правки?
3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить

1. Стратегию кэширования и инвалидации.
2. Транзакции, изоляцию и риск блокировок.
3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта

1. Обучение: Базы данных
2. Обучение: Node.js
3. Карта подготовки: Базы данных

20. Как объяснить trade-offs хранения JSON в SQL БД?

Теги: database, sql Сложность: Middle/Senior

Короткий ответ

JSON в SQL удобен для гибкости, но усложняет индексацию и валидацию схемы.

Что сказать на интервью (30-60 секунд)

1. Где это применяется: Критично для производительности API, целостности данных и масштабируемости продукта.
2. Главный риск: Оптимизация без EXPLAIN и реальных метрик часто маскирует проблему и ухудшает write/read баланс.
3. Как проверяете решение: Фиксирую query-budget, прогоняю regression-набор и контролирую блокировки/конкуренцию транзакций.

Мини-пример

EXPLAIN ANALYZE
SELECT * FROM orders
WHERE user_id = $1
ORDER BY created_at DESC
LIMIT 20;

Куда дальше

1. Вернитесь в модуль: Базы данных.
2. Сверьтесь с картой темы: Базы данных.
3. Продолжайте по маршруту: Senior трек.
4. Закрепите один ответ на практике в Песочнице.

Углубление (2-3 минуты)

1. Свяжите тему "Как объяснить trade-offs хранения JSON в SQL БД?" с одним production-сценарием и объясните, почему она влияет на результат.
2. Сравните baseline и after на реалистичном наборе данных.
3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки

1. Не учитывают write-cost и блокировки при оптимизации чтения.
2. Добавляют индексы без анализа плана запроса и профиля нагрузки.
3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы

1. Как решение повлияет на write path и блокировки?
2. Как изменится план запроса после вашей правки?
3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить

1. Стратегию кэширования и инвалидации.
2. Индексы, план запроса и N+1/батчинг.
3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта

1. Обучение: Базы данных
2. Обучение: Node.js
3. Карта подготовки: Базы данных