Лид: зачем зубрить теорию до доски
Репликация, шардирование, транзакции и гарантии доставки всплывают на каждом втором System Design. Не как отдельный экзамен — как проверка, что вы не рисуете «Kafka и Redis» вслепую.
Ниже — 12 вопросов с таблицами и формулировками, которые обычно ждут. Это шпаргалка редакции, не секретный банк конкретной компании. Формат доски разобран в гайде Amazon System Design; поиск и ранжирование — в разборе Авито.
Знание есть, а речь срывается — проговорите схему на моке с напарником. Дыру в терминах ловит квиз. Оффер не выдаём.
1. Что такое репликация
Репликация — несколько живых копий данных на разных узлах. Цель не «положить файл на полку», а держать доступность и размазать чтение.
| Цель | Что даёт |
|---|---|
| Доступность | Упал один узел — отвечает реплика |
| Чтение | Запросы читают с реплик, лидер не один на всех |
| Гео | Данные ближе к пользователю — меньше RTT |
| Отказ железа | Копия на другом сервере переживает диск |
Как обычно рисуют
- Клиент пишет в лидер (мастер).
- Лидер отдаёт изменения репликам.
- Чтение часто идёт в реплики — с лагом, если репликация асинхронная.
2. Что такое шардирование
Шард — независимый кусок данных на своём сервере. Горизонтальный раздел: каждый шард хранит уникальное подмножество, не полную копию.
Репликация не лечит запись в один лидер. Когда вертикаль закончилась, режут ключ и ставят роутер.
Типичная схема
- Приложение спрашивает роутер, какой шард.
- Шард 1 держит, например, A–I; шард 2 — J–R; шард 3 — S–Z.
- Каждый шард обычно ещё и реплицируют — иначе один диск кладёт целый диапазон.
3. Какие виды баз вы знаете
Перечень без «почему» на раунде звучит как вики. Для каждой строки держите пример задачи.
| Тип | Примеры | Когда |
|---|---|---|
| Реляционные | PostgreSQL, MySQL | Схема, ACID, связи |
| Документные | MongoDB, CouchDB | Гибкий JSON, быстрый старт |
| Колоночные | Cassandra, HBase, ClickHouse | Аналитика, широкие агрегации |
| Ключ-значение | Redis, DynamoDB | Кэш, сессии, доступ по ключу |
| Графовые | Neo4j | Связи: соцграф, рекомендации |
4. Какие индексы вы знаете
| Тип | Для чего | Ограничение |
|---|---|---|
| B-дерево / B+ | Равенство и диапазоны, сортировка | Точечный поиск O(log n), не O(1) |
| Хэш | Только = |
Нет диапазонов и ORDER BY по ключу |
| Составной | Несколько полей в одном ключе | Порядок колонок важен |
| Полнотекстовый | Поиск по тексту | Свой движок и настройки |
| Пространственный | Гео | GIS, не общий случай |
| Кластерный | Физический порядок строк | Обычно один на таблицу |
| Некластерный | Отдельная структура + указатели | Лишний lookup к таблице |
| Критерий | B-tree | Хэш |
|---|---|---|
| Точечный поиск | O(log n) | O(1) |
| Диапазон | Да | Нет |
| Сортировка по ключу | Да | Нет |
5. Forward и reverse proxy
| Критерий | Forward | Reverse |
|---|---|---|
| Стоит перед | Клиентами | Серверами |
| Кто скрыт | Клиент от сервера | Сервер от клиента |
| Задачи | Доступ, анонимность, кэш исходящего | Баланс, TLS, защита бэкенда |
| Пример | Корпоративный прокси, VPN | Nginx, HAProxy |
Одной фразой
Forward представляет клиентов перед интернетом. Reverse представляет ваш кластер перед клиентами. На SD почти всегда имеют в виду reverse: Nginx перед API.
6. Алгоритмы балансировки
| Алгоритм | Принцип | Минус |
|---|---|---|
| Round Robin | По очереди | Не видит живую нагрузку |
| Weighted RR | С весами мощности | Веса надо крутить руками |
| Least Connections | Кто меньше держит сессий | Сложнее, чем RR |
| IP Hash | Хэш IP → тот же бэкенд | NAT склеивает клиентов |
| Least Time | Задержка плюс соединения | Нужны живые метрики |
Пример
Round Robin: 1→A, 2→B, 3→C, 4→A. Least Connections: A держит 10, B — 3, C — 7 → новый запрос на B.
Таблицу с раунда не зачитывают
Интервьюер ждёт, что вы выберете алгоритм под нагрузку и скажете минус. Один раз проговорите это вслух — дешевле, чем молчаливая схема.
7. 2PC и 3PC
| Критерий | 2PC | 3PC |
|---|---|---|
| Фазы | Prepare → Commit | CanCommit → PreCommit → DoCommit |
| Падение координатора | Участники могут зависнуть в блокировке | Меньше блокировок, сложность выше |
| На практике | Классические СУБД | Редко; чаще Saga |
8. Transaction outbox и inbox
| Критерий | Outbox | Inbox |
|---|---|---|
| Сторона | Отправитель | Получатель |
| Цель | Не потерять событие после коммита | Не обработать дубль |
| Как | Пишем в outbox в той же транзакции, CDC/поллер шлёт в Kafka | Пишем id в inbox, если новый — обрабатываем |
Цепочка
Отправитель: бизнес-транзакция → outbox → брокер. Получатель: брокер → inbox → проверка id → обработка. Вместе это и есть бытовой exactly-once на уровне приложения.
9. Чем репликация отличается от бэкапа
| Критерий | Репликация | Бэкап |
|---|---|---|
| Зачем | Живая доступность | Аварийное восстановление |
| Данные | Актуальные, с лагом режима | Снимок на момент времени |
| Трафик | Да, чтение и failover | Нет, только restore |
| Логическая ошибка | Не спасает: DELETE уедет везде | Спасает, если снимок раньше ошибки |
10. Способы партиционирования
| Способ | Плюс | Минус |
|---|---|---|
| Range | Простые range-запросы | Hot shard на «свежих» ключах |
| Hash | Ровнее нагрузка | Нет дешёвого range scan |
| List | Явные корзины | Ручное управление |
| Geo | Локальность и закон о данных | Сложнее роутинг |
| Modulo id % N | Просто объяснить | Больно менять N |
11. Синхронная, асинхронная, полусинхронная
| Режим | Лидер ждёт | Лаг | Потеря данных |
|---|---|---|---|
| Синхронная | Все реплики | Выше | Минимальна |
| Асинхронная | Никого | Ниже | Есть, если лидер умер до слива |
| Полусинхронная | Хотя бы одну | Средний | Ниже, чем у async |
12. At-most, at-least, exactly-once
| Гарантия | Потери | Дубли | Где уместно |
|---|---|---|---|
| At-most-once | Да | Нет | Логи, некритичные метрики |
| At-least-once | Нет | Да | Большинство очередей |
| Exactly-once | Нет | Нет | Деньги, если умеете идемпотентность |
Как сказать
- At-most: отправил и забыл. Потеря допустима.
- At-least: нет ACK — шлём снова. Дубль должен пережить потребитель.
- Exactly-once — не магия брокера. Это at-least-once плюс inbox / дедуп / идемпотентный ключ.
Чеклист перед раундом
| № | Тема | Проверьте себя |
|---|---|---|
| 1 | Репликация | Отличие от бэкапа за 30 секунд |
| 2 | Шарды | Три стратегии и hot spot |
| 3 | Виды БД | Пример задачи на каждый тип |
| 4 | Индексы | B-tree vs хэш без мифа про равенство |
| 5 | Прокси | Кто кого скрывает |
| 6 | Баланс | Пять алгоритмов и когда RR врёт |
| 7 | 2PC / 3PC | Почему Saga чаще |
| 8 | Outbox / inbox | Связь с идемпотентностью |
| 9 | Бэкап | DELETE на всех репликах |
| 10 | Партиции | Range vs hash |
| 11 | Режимы | Latency vs потеря записи |
| 12 | Доставка | Exactly-once как семантика |
Если до слота меньше недели — сначала плейбук последней недели, не новый учебник. Речь на доске тренируют парным моком.
Частые вопросы
Нажмите на вопрос — ответ откроется ниже.
Нет. Реплика живая и отвечает на трафик. Ошибочный DELETE уедет на все копии. Бэкап — снимок, с которого поднимаетесь.
Реплики масштабируют чтение. Шарды — когда запись не лезет на один лидер. Часто оба: каждый шард ещё реплицируют.
На раунде честнее сказать: at-least-once плюс идемпотентность (inbox, ключ дедупа). Брокер не снимает с вас дубли на потребителе.
Фазы знать стоит. Дальше — почему Saga популярнее: блокировки и координатор. Структура ответа как в разборе System Design, не три стрелки наизусть.
Нет отдельного симулятора Amazon или Авито. Есть мок и квиз. Бот @it_careergym_ru_bot — опциональный канал мэтча, не ментор «как в FAANG». Оффер не обещаем.
Что дальше
Теория закрывает первые десять минут раунда. Дальше — нагрузка, узкие места и речь. IT Career Gym — тренажёр: мок, квизы, разборы в блоге. Это подготовка, не трудоустройство.
Пока слот не открылся
Соберите заявку на мок и закройте одну тему в квизе. Оффер мы не выдаём — формулировки к доске подтянуть можно.
Также по теме: System Design как на Amazon · Собеседование в Авито · System Design в DoorDash · Парный мок · Плейбук последней недели