title: Конспект материала 13 — YouTube-канал ByteByteGo source: https://www.youtube.com/channel/UCZgt6AzoyjslHTC9dz0UoTw author: Alex Xu и команда ByteByteGo конспект: подготовлено 2026-09-18, TASK-45.17; выгружен полный список канала (142 видео, yt-dlp), отсмотрены субтитры топ-5 (полная расшифровка); тезисы топ-5 — по тексту видео, второй эшелон — навигатор по названиям/сериям без просмотра статус: P3-источник. Роль канала — не новая фактура (кейсы уже в конспекте блога, материал 12), а формат: 5–10-минутные анимации для повтора вслух перед слотами + единственный на канале mock-подобный разбор чата. Топ-5 = ~40 минут на один вечер; больше канала не нужно

Материал 13: YouTube-канал ByteByteGo — индекс

Анимационные версии статей ByteByteGo: 142 видео, хронометраж 2–10 минут (есть пара длинных mock-разборов). Это не учебник и не банк кейсов — обе роли уже закрыты (SDP/karanpratapsingh/DDIA и конспект блога №12). Ценность канала — формат повторения: видео смотрится быстрее, чем перечитывается конспект, и заставляет проговаривать структуру вслух — то, что нам надо тренировать перед секцией. Плюс два формата, которых нет в блоге: mock-подобные разборы дизайна (чат, YouTube, LBS) и визуальные объяснения концептов за 5 минут.

1. Как устроен источник

2. Критерии отбора топ-5

1. Формат секции: крупноблочная схема сервиса класса инстаграм/твиттер + отказоустойчивость — нужен разбор-прогонка и каркас ответа.
2. Закрывают то, чего нет в других материалах: mock-прогонка чата (нет в блоге), видео-фреймворк (дубль методички — удобен для повтора), BoE-методика, HA-стратегии, процесс выбора хранилища.
3. Не дублировать уже покрытое: latency numbers (Crash Course #1) — дубль материала 21 (interactive latency); Kafka-видео — дубль EP203 и «Why is Kafka fast?» из конспекта блога; кейс-стади — дубль №11/№12. Всё это — во второй эшелон.

3. Топ-5 видео

3.1 Design A Chat System (8:45) — сквозной кейс-прогонка

Выжимка. Скоуп: 1-на-1 + группы до 100 участников, гарантия доставки, хранение для офлайн ограниченное время, presence (зелёная точка). Протоколы: HTTP — только на отправку (клиент инициирует, для приёма плох); polling — пустые запросы жгут сервер; long polling — лучше, но WebSocket лучше всех: после HTTP-handshake апгрейд до постоянного канала, однако stateful-соединения сложно скейлить. Итог — гибрид: HTTP на отправку (stateless, масштабируется добавлением серверов), WebSocket на приём. Архитектура в трёх слоях: stateless-сервисы (auth, профили, отправка, REST + LB) → stateful-ядро, чат-серверы (десятки–сотни тысяч WS-соединений на сервер — эта ёмкость определяет число серверов) → third-party push (APNs/FCM) для офлайн. Inbox pattern: у каждого пользователя персональная очередь; онлайн — доставка сразу + ack; офлайн или сбой — сообщение ждёт в инбоксе; сервер удаляет только после ack, нет ack — ретрай; при подключении — выгрузка накопленного по порядку. Роутинг между серверами: presence service (каталог user → чат-сервер) + прямой RPC между серверами (паттерн Discord); офлайн — инбокс + push. Группы до 100: fan-out по членам группы (онлайн — RPC, офлайн — в инбокс), нагрузка линейна размеру группы — приемлемо. Presence: WS-ping каждые 30 с, нет пинга 60 с — офлайн (сглаживает лифты и тоннели). Что ломается первым при росте: соединения → больше чат-серверов; БД инбоксов → шардирование по user_id; глобальность → мульти-регион (ближайший регион, кросс-регионный роутинг = новая сложность). За кадром оставлено (назвать на секции): порядок сообщений (timestamps, vector clocks), E2E-шифрование, медиа (CDN, прогрессивная загрузка), typing indicators, rate limiting.

Что брать на секцию. - Единственный на канале почти полный прогон секции: скоуп → протоколы → слои → гарантия доставки → масштабирование. Сверять структуру своего ответа с этим порядком. - Это вариация нашего мессенджера (../classic-designs.md §3) — использовать как сверку: гибрид HTTP+WS, inbox + ack, presence-сервис, шардирование инбоксов по user_id. - Готовая формулировка про WS: «WebSocket stateful, поэтому держим его только там, где без него нельзя — на доставке; отправку оставляем на HTTP» — прямой ответ на вопрос «как скейлить WS» из step-by-step гайда (§3.2). - Триада «протокол → где state → что ломается первым» — мини-шаблон рассуждения для любого real-time кейса.

3.2 System Design Interview: A Step-By-Step Guide (9:53) — фреймворк

Выжимка. Видео-версия фреймворка из книг Alex Xu. 4 шага на 45–60-минутную секцию (мясо ~35–45 мин): (1) понять проблему и скоуп (~5 мин) — задача намеренно размыта, прыгать в решение — red flag; зафиксировать топ-фичи и согласовать список с интервьюером; нефункциональные требования — масштаб и производительность, именно они делают задачу интересной, и чем senior-роль, тем они важнее; грубый BoE для порядка величин. (2) high-level + buy-in (~20 мин) — top-down с API (REST; двусторонняя связь → WebSocket, socket-сервис stateful и его эксплуатация на масштабе — тема deep dive); диаграмма = blueprint, по ней проверить каждую фичу end-to-end (LB/gateway → сервисы → хранилище); data model и schema, read/write ratio; конкретную БД можно отложить до deep dive. Pro tip: вести список discussion points на потом, не закапываться до полной картины. (3) deep dive (~15 мин) — выбрать 2–3 проблемы; каркас каждой: сформулировать проблему (например, write QPS 1M/сек не тянет одна БД) → минимум два решения → трейдоффы с числами → выбрать и согласовать; «read the room» — читать реакцию интервьюера и закрывать его сомнения. (4) wrap up (~5 мин) — короткое резюме уникальных частей + вопросы интервьюеру о компании.

Что брать на секцию. - Это дубль ../methodology.md §2 в видео-формате — смотреть не для новой информации, а как репетицию: поставить на 2x и проговорить тайминг своих 45 минут. - Две формулировки, которые стоит забрать дословно: «чем senior-роль, тем важнее нефункциональные требования» (оправдывает наши оценки числами с первой минуты) и «deep dive — где нефункциональные требования делают задачу интересной» (мост от схемы к обсуждению). - Правило «2–3 проблемы за deep dive, по каждой ≥2 решения с числами» — чек против нашей главной зоны роста: проговаривания сложности и трейдоффов.

3.3 Back-Of-The-Envelope Estimation / Capacity Planning (8:31) — числа

Выжимка. Цель BoE — sanity check дизайна, порядок величин, не точность («в пределах 1–2 порядков — достаточно»). Методика RPS: DAU × доля пользующихся фичей × среднее число действий × peak-фактор / 86400. Пример (числа условные): Twitter 300M MAU × 50% = 150M DAU × 25% постящих × 2 твита × peak 2 (утренний пик) / 10^5 сек ≈ 1500 твитов/сек. Peak-фактор обязателен: у карт 5× в час пик, у такси 2× в выходные — проектируем под пик, там где система ломается. Техника счёта: всё в научную нотацию (умножение степеней → сложение показателей), 86400 сек ≈ 10^5, год ≈ 400 дней (округление вверх), выучить ряд 10^3/10^6/10^9/10^12 (KB/MB/GB/TB). Второй пример — сторедж медиа: 150M твитов/день × 10% с фото × 100 KB × 5 лет × 3 копии ≈ 9 PB фото; видео при размере в 1000× больше и популярности в 10× ниже = 100× от фото = 900 PB. Как читать результат: 1M rps при 10K rps на сервер = 100 серверов за LB; а 10 qps на БД = одна машина, шардирование и кэш пока не нужны.

Что брать на секцию. - Формула RPS через peak-фактор — наша стандартная цепочка оценок (KB §2): на секции всегда называть пик, а не среднее. - Приёмы против арифметических ошибок под стрессом: научная нотация + округления 10^5 сек/сутки — считать на доске столбиком из больших чисел нельзя. - Хрестоматийный вывод «из оценки следует архитектура»: 100 серверов → LB обязателен; 10 qps → не усложняем. Оценка без следствия — потерянное время.

3.4 8 Most Important Tips for Designing Fault-Tolerant System (5:11) — отказоустойчивость

Выжимка. Триада понятий, которые на секции часто смешивают: replication — копии данных (Cassandra держит каждую единицу на нескольких нодах); redundancy — запасные компоненты (active-active за LB / active-passive со standby; RAID0 без избыточности vs RAID1 зеркало); failover — механизм переключения: мониторинг здоровья + редирект трафика на standby. Дальше: load balancing (round robin → алгоритмы с учётом нагрузки и здоровья); graceful degradation — при перегрузке режем некритичное (realtime-комментарии), сохраняем ядро (лента и постинг), плюс circuit breakers против каскадных отказов; мониторинг и алертинг — Prometheus (метрики: CPU, error rate, latency) + Grafana (дашборды) + PagerDuty (пейджинг): все стратегии бесполезны, если не знаешь, что сломалось. Сборка на примере AWS: приложение в каждой AZ, синхронная репликация БД между зонами, автоматический failover. Финальная оговорка: всё это — сложность, стоимость и время разработки, осознанная инвестиция в надёжность.

Что брать на секцию. - Самый сжатый легальный словарь блока HA (KB §9): 5 минут — и можно говорить терминами без пауз: replication ≠ redundancy ≠ failover. - Graceful degradation с конкретикой «что режем первым» — готовый ответ на «сервис деградирует, что делаем?»: троттлим realtime-эпфемы, ядро (лента, постинг) не трогаем; circuit breaker как страховка от каскада. - Фраза-вывод для блока эксплуатации (KB §10): «HA-механизмы работают, только если мониторинг замечает отказ раньше пользователя» — и наш плюс: observability не должна зависеть от наблюдаемой системы (урок GCP-кейса из конспекта блога §3.2).

3.5 How To Choose The Right Database? (6:58) — выбор хранилища

Выжимка. Неожиданный заход: выбор новой БД — последний шаг. Сначала доказать, что текущая исчерпана: симптомы (p95 улетел, working set не влезает в память) лечить по порядку — прочитать мануал своей БД от корки до корки (крутилки: размер working set, стратегия compaction, поведение GC), затем выжать headroom приложением: кэш, read-реплики, шардирование/партиционирование. Мотив: миграция живой боевой БД — долго (дольше, чем кажется) и рискованно. Если выбирать новую: boring is good — старая и обстрлянная, с рынком опытных админов; в финансах консервативнее. No free lunch: за «бесконечным горизонтальным масштабированием» прячется цена — читать в мануале страницы Limits и FAQ («чем громче обещания, тем длиннее дисклеймер»); типичная цена NoSQL: ослабленные транзакции + жёсткая модель данных (денормализация, одинаковые данные в нескольких коллекциях, нет запросов между сущностями). Финальный этап — shoot-out: бенчмарк на своих данных и своих паттернах; смотреть p99, не среднее; ломать специально (failover ноды, сетевые партиции, up/down-шардирование). Потом детальный план миграции, peer review, сначала маленький сервис; на масштабе миграция может занять годы.

Что брать на секцию. - Каркас ответа на «какую БД выберете?» (KB §3, статья 04): сначала от требований (паттерны доступа, консистентность) → потом от ограничений (страница Limits = где честно) → boring is good как дефолт. - Готовый зрелый ход, отличающий senior-ответ: «прежде чем менять хранилище — крутилки, кэш, реплики; миграция — последний вариант» — редкий кандидат это проговаривает. - «Смотрим p99, а не среднее» — фраза-маркер для блока эксплуатационной зрелости (KB §10); связка с latency-числами (материал 21).

4. Второй эшелон (навигатор, не просмотрено)

Тезисы по названиям и известному содержанию серий — при использовании посмотреть. Сгруппировано по разделам брифа.

Что на канале есть, но на секцию не нужно: инженерная база ниже уровня секции (HTTP/DNS/SSH/git/OAuth/JWT/SSO, Linux, Docker/K8s-популяризация) и AI/LLM-волна 2025–2026 (Transformers, AI Agents, MCP, Lakehouse) — последняя может пригодиться позже под AI-витрину профиля, но это вне TASK-45.

5. Как использовать перед слотами

1. Вечер накануне (топ-5 целиком, ~40 минут): чат-прогонка → step-by-step → BoE → HA-советы → выбор БД. После каждого видео — пересказ вслух за 60 секунд (протокол ../methodology.md §6).
2. Днём перед секцией: только §3.1 (чат) как разминка структуры + §3.4 (HA-словарь) как лексическая зарядка.
3. Точечно при провалах тренировок: фаны по слабым блокам из §4 (кэш-питфолы, consistent hashing, CAP, deployment strategies).
4. Чего на канале нет и куда идти: глубокая фактура кейсов — блог №12 и system-design-101 №11; фреймворк в полном виде — ../methodology.md; числа — KB §1–2; устройство хранения — DDIA-карта KB §12.

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

• ../knowledge-base.md — §1–2 (числа и оценки), §3 (хранилища), §4 (кэш), §5–6 (репликация/шардирование), §7 (консистентность), §8 (очереди), §9 (отказоустойчивость), §10 (эксплуатация)
• ../classic-designs.md §3 (мессенджер), §4 (медиа-хостинг) — родные разборы для кейсов канала
• ../methodology.md §2 (фреймворк), §4 (ошибки), §6 (протокол тренировки)
• lsd-bytebytego-blog.md — тот же автор, текстовая версия: банк кейсов и EP-карточек (№12)
• learn-system-design-index.md — индекс подборки (этот материал — №13, P3)