title: Конспект материала 11 — ByteByteGoHq/system-design-101 source: https://github.com/ByteByteGoHq/system-design-101 author: Alex Xu и команда ByteByteGo конспект: подготовлено 2026-09-18, TASK-45.15; изучены классический README (60+ диаграмм, 14 секций, состояние до реструктуризации 04.2025) и актуальная структура репо (400 гайдов в data/guides, 15 категорий); вычитаны тексты ~25 гайдов-кандидатов на досочную выборку статус: P2-источник к слотам 21–22.09. Не учебник, а визуальный словарь: 1 диаграмма = 1 концепт. Ценность для нас — референсы «как концепт выглядит на доске» (§4–§5), карта тем для самопроверки (§3) и кейс-стади как устные аргументы (§6)

Материал 11: system-design-101 — визуальный словарь системного дизайна

Самый популярный репозиторий по системному дизайну (150k+ звёзд). Формат: каждая тема — одна диаграмма плюс страница текста. Это не учебник с последовательным изложением (роль учебников у нас играют SDP, karanpratapsingh и DDIA), а каталог готовых визуальных референсов: «как выглядит концепт X, нарисованный правильно». Для подготовки к секции это ровно то, что нужно на этапе тренировки доски: перерисовать чужую правильную схему по памяти проще, чем изобретать свою.

1. Как устроен источник (важно: у репо две эпохи)

Практический вывод: гайды не удалялись — они переехали и размножились (60 → 400). Читать подряд не нужно и невозможно; работать надо от нашей задачи (что уметь рисовать), а не от каталога. §3 даёт карту категорий, §4–§6 — отбор.

2. Словарь концептов: как читать этот источник

Каждый гайд отвечает на вопрос «как работает X» или «чем X отличается от Y». Три режима использования перед секцией:

1. Референс для доски. Перед тренировкой схемы открыть соответствующую диаграмму, перерисовать по памяти, сравнить. Чужая композиция подсказывает, что рисовать в каком порядке и какими блоками (§4–§5).
2. Словарь самопроверки. Пройтись по заголовкам гайдов как по чек-листу: «могу ли я на доске за минуту объяснить этот концепт?» — где «нет», там и повторять (§3).
3. Банк аргументов. Кейс-стади реальных компаний — готовые ответы на вопрос «а как в реальности?» (§6).

Репо не даёт: сквозного фреймворка ответа (это ../methodology.md §2), чисел для оценок (KB §1–2), эталонных разборов кейсов (это ../classic-designs.md).

3. Карта тем по категориям (400 гайдов, приоритет для нашей секции)

4. Диаграммы тира 1 — ядро доски (тренировать до автоматизма)

Критерий отбора: диаграмма нужна в любом кейсе нашей секции («крупноблочная схема сервиса класса инстаграм/твиттер + отказоустойчивость») или является типовым элементом deep-dive. Формат: что рисуем → когда на секции → где референс.

4.1 Сквозная крупноблочная схема — главная диаграмма секции

Рисуем: клиент → DNS → CDN (статика) → LB (публичный вход) → API gateway (аутентификация, rate limit, маршрутизация) → сервисы (по доменам) → распределённый кэш (Redis) → БД primary + реплики; параллельной дорожкой — очередь → воркеры; по краю — service discovery, identity provider, мониторинг/логи.

Когда: первые 15 минут секции, «high-level design» — это и есть та самая «крупноблочная схема» из брифа. Каждый блок на схеме = готовый deep-dive, если интервьюер ткнёт.

Референсы: «What does a typical microservice architecture look like?» (композиция блоков), «10 Essential Components of a Production Web Application» (порядок обхода: CI/CD → DNS → LB/reverse proxy → CDN → API → БД/кэш → job queue → поиск → мониторинг → алертинг), «Must Know System Design Building Blocks» (6 групп блоков). Детали блоков — KB §13, §3–§10.

4.2 Кэш во всех слоях («Data is cached everywhere»)

Рисуем: вертикальную дорожку запроса с 8 уровнями кэширования: браузер (HTTP-cache) → CDN → LB → память/CPU-кэш сервиса → распределённый кэш (Redis) → полнотекстовый индекс (ES) → внутри БД (WAL, buffer pool, materialized view, transaction log). У каждого уровня подписать политику устаревания.

Когда: тема «где кэш и почему» — почти гарантированный вопрос в кейсе ленты (лента = классический hot read). Плюс это заготовка ответа «как снизить нагрузку на БД».

Референс: «Data is cached everywhere» (классический README). Связка: KB §4 (стратегии, инвалидация, hot key), lsd-ultimate-guide-image.md (маршрут запроса).

4.3 Пять кэш-стратегий (cache-aside, read-through, write-around, write-through, write-back)

Рисуем: три участника (клиент — кэш — БД) и последовательности стрелок для каждой стратегии; рядом трейдоффы: write-back — быстрое запись/риск потери, write-through — консистентность/латентность записи, cache-aside — простота/рассинхрон.

Когда: deep-dive кэша в любом read-heavy кейсе. Уметь назвать комбинацию по умолчанию: cache-aside + write-around.

Референс: «Top caching strategies». Связка: KB §4, lsd-leetcode-template.md (карточка §7).

4.4 Репликация: primary + read replicas

Рисуем: primary (все записи) → 2–3 реплики (чтения); стрелки запросов от сервисов; отдельным элементом — replication lag и проблему read-after-write («создал заказ — не видит его в истории»).

Когда: масштабирование чтения в ленте/каталоге; сразу вслед за схемой БД. Обязательно назвать лаг и способы его обойти: критичные чтения → primary, read-after-write → primary, проверка caught-up.

Референс: «Read Replica Pattern» (сценарий с Alice и заказом — хорошо пересказывать как мини-историю). Связка: KB §5 (типы репликации, консистентность), §9.

4.5 Отказоустойчивый контур вокруг сервиса (вторая главная диаграмма секции)

Рисуем: сервис-прямоугольник, вокруг — восемь контуров защиты: timeout, retry (backoff + jitter), circuit breaker (closed/open/half-open), rate limiting, load shedding, bulkhead (пулы по зависимости), backpressure, «let it crash»; плюс health checks/heartbeat от мониторинга.

Когда: вторая половина секции — «отказоустойчивость» заявлена в брифе прямо. Рисуем контур поверх крупноблочной схемы: на каждый внешний вызов.

Референсы: «Resiliency Patterns» (8 паттернов), «How do we retry on failures» (4 стратегии backoff: linear, linear+jitter, exponential, exponential+jitter), «How do we detect node failures in distributed systems» (варианты heartbeat: push/pull, с health-данными, с таймстемпами, с ack, с кворумом). Связка: KB §9 (полная версия с байками DDIA), §11 (лексика).

4.6 Очередь и асинхронная обработка: producer → партиции → consumer group

Рисуем: продюсер → топик с 3–4 партициями → consumer group; рядом — delivery semantics (at-most/at-least/exactly-once) и идемпотентный консьюмер (дедуп по ключу); для full-версии — DLQ.

Когда: любое «а что с пиковой нагрузкой на запись» — буферизуем очередью; фоновые задачи (медиа, нотификации, счётчики). Обязательно проговорить выбор семантики доставки и почему exactly-once дорого.

Референсы: «Types of Message Queues» (критерии выбора), «Delivery Semantics» (три семантики + юзкейсы), «Can Kafka Lose Messages?». Связка: KB §8 (полная версия).

4.7 «Почему Kafka быстрый»: sequential I/O + zero copy

Рисуем: два пути чтения с диска до сетевой карты: без zero-copy (4 копии: диск → OS cache → приложение → socket buffer → NIC) и с zero-copy (sendfile(), мимо приложения). Рядом — append-only запись (sequential I/O).

Когда: deep-dive очередей; это готовый ответ на «почему Kafka, а не RabbitMQ» в части производительности. Заодно демонстрирует знание системного уровня.

Референс: «Why is Kafka fast» (есть в обеих эпохах репо — классика). Связка: KB §8.

4.8 Шардирование: 4 алгоритма + кольцо consistent hashing

Рисуем: таблицу/набор шартов; четыре способа маршрутизации: range (по диапазону ключа), hash (hash(key) % N), consistent hashing (кольцо), virtual buckets (двухуровневая схема bucket → шард). Для кольца — виртуальные ноды и что происходит при добавлении ноды (переезжает только 1/N ключей).

Когда: масштабирование записи; вопрос «что будет при добавлении ноды» — ловушка, на неё и отвечаем кольцом. Простое hash % N → шторм перестроек.

Референсы: «Top 4 Data Sharding Algorithms Explained», «Consistent Hashing Explained» (примеры: DynamoDB, Cassandra, Discord, Akamai CDN). Связка: KB §6 (виртуальные ноды, hot partition), lsd-karanpratapsingh-system-design.md.

4.9 Fan-out ленты: write vs read

Репо подходит к ленте через кейс-стади (Twitter 2012 vs 2022, «For You» за 1.5 с), а не отдельной диаграммой — но именно здесь наш главный кейс. Рисуем: fan-out on write (пуш в ленты подписчиков при твите, кэш-листы в Redis) против fan-out on read (сборка ленты при запросе) и гибрид для аккаунтов-миллионников.

Когда: ядро кейса «инстаграм/твиттер». Детальный разбор — не здесь, а в ../classic-designs.md §2 (эталон уже собран); от репо берём визуальные референсы и аргумент «как у Twitter в реальности» (§6).

4.10 HA-схемы: primary-backup / primary-secondary / primary-primary

Рисуем: три мини-схемы пары нод: backup стоит холодным (ручное переключение), secondary тянет чтения (но лаг → несовместимость данных), primary-primary пишут оба (нужен reconciliation). Рядом — формула «4 девятки = 52.5 мин простоя в год».

Когда: вопрос «что будет, если упадёт БД/зона» — вместо абстрактного «развернём реплики» рисуем конкретную схему и называем цену каждой.

Референс: «How to Design for High Availability». Связка: KB §9 (active-active vs active-passive, арифметика надёжности).

5. Диаграммы тира 2 — второй эшелон (deep-dive и вопросы «а как именно»)

Уметь нарисовать упрощённо по просьбе интервьюера; полностью выучивать не обязательно.

6. Кейс-стади — устные аргументы (не рисуем, а рассказываем)

Главная валюта репо для нашей секции: готовые реальные примеры с цифрами, которые вставляются в ответ как «кстати, в реальности…».

7. Как использовать материал под слоты 21/22.09

По индексу (learn-system-design-index.md §4) это P2-материал со сценарием «визуальный повтор по слабым местам из self-review». Конкретный протокол:

1. Не читать подряд. Ни 400 гайдов, ни классический README целиком — до секции это запрещено принципом «ничего нового учебного» (index §4).
2. После каждого мока/self-review (methodology §6): выписать 2–3 места, где доска «поплыла», и найти соответствующую диаграмму в §4–§5 этого конспекта → перерисовать по памяти → сравнить с оригиналом (ссылки на гайды — по заголовку в data/guides или через поиск по репо).
3. Чек-лист самопроверки на доску (за 60 секунд по памяти + назвать трейдофф): крупноблочная схема (4.1) → кэш-слои (4.2) → репликация (4.4) → отказоустойчивый контур (4.5) → очередь (4.6) → кольцо шардирования (4.8). Шесть схем покрывают 90% нашего формата.
4. Кейс-стади из §6 — перечитать вечером перед слотом как список «аргументных карточек»: по одной фразе на кейс.
5. Диаграммы рисуются из головы, репо на секции недоступен; поэтому критерий — «воспроизвёл композицию и озвучил трейдофф», а не «запомнил картинку».

8. Уникальное относительно KB — кандидаты для 45.1

Большая часть материала — визуальное зеркало уже собранного (resiliency → KB §9; LB-алгоритмы → §13.2; транспорт → §13.3; ID → §13.4; локи → §13.5; CAP/PACELC → §7; delivery semantics → §8; latency/числа → §1–2). Новое, что стоит забрать в базу знаний:

• 8 индексных структур (skiplist/SSTable/inverted/suffix/R-tree) — расширение KB §3: сейчас классы хранилищ есть, а словарь «из чего состоит индекс» — частично в карте DDIA §12.
• Virtual bucket sharding как 4-й алгоритм шардирования (двухуровневая схема bucket → физический шард; перебалансировка без движения данных) — KB §6.
• CDC как стандартный ответ «как синхронизируем проекции/кэш/индекс» (транзакционный лог → Debezium → Kafka) — в KB упомянут вскользь, а это готовая альтернатива dual-write.
• Heartbeat-варианты (push/pull, с health-данными, с ack, с кворумом) — детализация KB §9 сверх «health checks liveness/readiness».
• «Let it crash» и backpressure как явные пункты списка изоляции — в KB §9 есть 6 из 8 паттернов.
• HA-триада primary-backup / secondary / primary с ценой каждой схемы — переупаковка KB §9 в более говоримые термины.
• Аргументные карточки §6 (Discord p99, Hotstar 2 с, Prime Video −90%, Stack Overflow 9 серверов) — в KB §11 нет готовых «цифр-примеров из реальности»; кандидаты в мини-шпаргалку.

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

• ../knowledge-base.md — §3 (хранилища), §4 (кэш), §6 (шардирование), §8 (очереди), §9 (отказоустойчивость), §11 (шпаргалка), §13 (блоки инфографики)
• ../methodology.md §6 — протокол само-тренировки (сюда встраивается шаг 2 из §7)
• ../classic-designs.md §2–§4 — эталонные разборы ленты/мессенджера/медиа (схемы 4.9, 5.2, 5.17 — визуальные референсы к ним)
• learn-system-design-index.md — индекс подборки (материал 11, P2)
• конспекты соседних материалов: lsd-karanpratapsingh-system-design.md (45.13), lsd-bregman-notebook.md (45.14), lsd-ultimate-guide-image.md (45.24)