---
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. Как устроен источник

| Формат | Что это | Доля | Ценность для нас |
|---|---|---|---|
| **Mock-подобные разборы дизайна** | «Design A Chat System», «Design YouTube», «Design a Web Crawler», «Design a Location Based Service» (24 мин) | ~5% | **Ядро**: сквозная прогонка кейса от скоупа до масштабирования — сверка нашей структуры ответа |
| **Концепт-рефрешеры** | 5–10-минутные анимации по одному концепту (кэш, consistent hashing, CAP, BoE, fault tolerance) | ~45% | Повтор перед слотами: «посмотрел — пересказал своими словами» |
| **Кейс-стади реальных систем** | Discord, Stack Overflow, Hotstar, Prime Video, Netflix, Google storage | ~15% | Аргументы «а как в реальности» — дублируют кейсы из блога (№12) и system-design-101 (№11) |
| **Инженерная база вне секции** | HTTP/DNS/SSH/git/OAuth/JWT/Linux, DevOps-инструменты | ~20% | Не для секции (уровень ниже); пропускаем |
| **AI/LLM-волна 2025–2026** | Transformers, AI Agents, MCP, Data Lakehouse, LLMs locally | ~15% | Не для секции; в перспективе — под AI-витрину профиля (отдельный план, не TASK-45) |

## 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 видео

| # | Видео | Дата | Длит. | Тема | Куда ложится |
|---|---|---|---|---|---|
| 1 | [Design A Chat System (WhatsApp, Messenger, Discord, Slack)](https://www.youtube.com/watch?v=okrR1KXNLtA) | 2025-09-22 | 8:45 | сквозной кейс-прогонка | `../classic-designs.md` §3 |
| 2 | [System Design Interview: A Step-By-Step Guide](https://www.youtube.com/watch?v=i7twT3x5yv8) | 2023-02-09 | 9:53 | фреймворк ответа | `../methodology.md` §2 |
| 3 | [Back-Of-The-Envelope Estimation / Capacity Planning](https://www.youtube.com/watch?v=UC5xf8FbdJc) | 2022-09-13 | 8:31 | оценки и числа | KB §1–2, статья 02 |
| 4 | [8 Most Important Tips for Designing Fault-Tolerant System](https://www.youtube.com/watch?v=3Lis4w4_bBc) | 2025-02-25 | 5:11 | отказоустойчивость | KB §9, статья 08 |
| 5 | [How To Choose The Right Database?](https://www.youtube.com/watch?v=kkeFE6iRfMM) | 2022-09-20 | 6:58 | выбор хранилища | KB §3, статья 04 |

### 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. Второй эшелон (навигатор, не просмотрено)

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

| Видео | Длит. | Тема | Зачем |
|---|---|---|---|
| [System Design Interview – BIGGEST Mistakes to Avoid](https://www.youtube.com/watch?v=OvufRkoD-D0) | 6:48 | формат секции | Пара к `../methodology.md` §4 (топ-10 ошибок) — сверка перед слотами |
| [How to Crack Any System Design Interview](https://www.youtube.com/watch?v=o-k7h2G3Gco) | 8:19 | формат секции | Вторая версия фреймворка, короче §3.2 |
| [Top 7 Ways to 10x Your API Performance](https://www.youtube.com/watch?v=zvWKqUiovAM) | 6:05 | прикладные компоненты | Пагинация, кэш, CDN — аргументы для шага «API» |
| [Scalability Simply Explained in 10 Minutes](https://www.youtube.com/watch?v=EWS_CIxttVw) | 9:20 | масштабирование | Вертикаль vs горизонталь целиком — дубль статьи 03 |
| [Vertical vs Horizontal Scaling](https://www.youtube.com/watch?v=dvRFHG2-uYs) | 4:34 | масштабирование | Карточка для быстрого повтора |
| [What is a LOAD BALANCER really about?](https://www.youtube.com/watch?v=LQuuoHTyYz8) / [Top 6 Load Balancing Algorithms](https://www.youtube.com/watch?v=dBmxNsS3BGE) | 6:45 / 5:18 | масштабирование | LB + алгоритмы — ядро статьи 03 |
| [Reverse Proxy vs API Gateway vs Load Balancer](https://www.youtube.com/watch?v=RqfaTIWc3LQ) / [What is API Gateway?](https://www.youtube.com/watch?v=6ULyxuHKxg8) | 3:06 / 3:26 | схемные карточки | Границы LB/gateway/proxy — частый уточняющий вопрос секции (ср. EP122/EP123 из конспекта блога §4) |
| [What Is A CDN? How Does It Work?](https://www.youtube.com/watch?v=RI9np1LWzqw) | 4:24 | масштабирование | Карточка CDN для схемы медиа |
| [Cache Systems Every Developer Should Know](https://www.youtube.com/watch?v=dGAgxozNWFE) / [Caching Pitfalls Every Developer Should Know](https://www.youtube.com/watch?v=wh98s0XhMmQ) | 5:48 / 6:41 | кэш (KB §4) | Паттерны + подводные камни; дублируют EP-карточки блога — брать как видео-повтор |
| [Why is single-threaded Redis so fast?](https://www.youtube.com/watch?v=5TRFpFBccQM) / [Top 5 Redis Use Cases](https://www.youtube.com/watch?v=a4yX7RUgTxI) | 3:39 / 6:28 | кэш (KB §4) | Event loop + не-кэш use cases Redis |
| [7 Must-know Strategies to Scale Your Database](https://www.youtube.com/watch?v=_1IKwnbscQU) | 8:42 | репликация/шардирование (KB §5–6) | Сводка стратегий: реплики, кэш, индексы, шардирование |
| [Consistent Hashing — Algorithms You Should Know #1](https://www.youtube.com/watch?v=UF9Iqmg94tk) | 8:04 | шардирование (KB §6) | Алгоритм на анимации — повтор перед секцией |
| [The Secret Sauce Behind NoSQL: LSM Tree](https://www.youtube.com/watch?v=I6jB0nM9SKU) / [8 Key Data Structures That Power Modern Databases](https://www.youtube.com/watch?v=W_v05d_2RTo) / [Bloom Filters #2](https://www.youtube.com/watch?v=V3pzxngeLqw) | 7:35 / 4:34 / 5:40 | хранилища (KB §3) | Внутренности хранилищ — глубина по DDIA (KB §12) в видео-формате |
| [Kafka vs RabbitMQ vs Messaging Middleware vs Pulsar](https://www.youtube.com/watch?v=x4k1XEjNzYQ) | 4:31 | очереди (KB §8) | Видео-версия EP203 (конспект блога §3.4) — выбор брокера |
| [Why is Kafka fast?](https://www.youtube.com/watch?v=UNUz1-msbOM) / [Apache Kafka In 3 Minutes](https://www.youtube.com/watch?v=HZklgPkboro) | 5:02 / 3:46 | очереди (KB §8) | Sequential I/O + zero-copy; основы лога |
| [CAP Theorem Simplified](https://www.youtube.com/watch?v=BHqjEjzAicA) / [KISS, SOLID, CAP, BASE](https://www.youtube.com/watch?v=cTyZ_hbmbDw) | 5:33 / 6:38 | консистентность (KB §7) | CAP/BASE на пальцах — словарь блока |
| [Top 7 Most-Used Distributed System Patterns](https://www.youtube.com/watch?v=nH4qjmP2KEE) | 6:14 | паттерны | Обзорная карта распределённых паттернов |
| [System Design Was HARD - Until You Knew the Trade-Offs, ч. 1](https://www.youtube.com/watch?v=1nENigGr-a0) и [ч. 2](https://www.youtube.com/watch?v=2g1G8Jr88xU) | 5:09 / 6:12 | трейдоффы | Каталог «решение → цена» — наша главная тема проговаривания |
| [How Discord Stores TRILLIONS of Messages](https://www.youtube.com/watch?v=O3PwuzCvAjI) / [Uncovering Stack Overflow's Architecture](https://www.youtube.com/watch?v=fKc050dvNIE) / [How Disney Hotstar Captures One Billion Emojis](https://www.youtube.com/watch?v=UN1kW5AHid4) / [Prime Video Ditches AWS Serverless, Saves 90%](https://www.youtube.com/watch?v=JTp0TY_2hXM) | 7:11 / 4:09 / 4:35 / 4:15 | кейс-стади | Аргументы «в реальности»; дублируют кейс-стади из №11/№12 — там уже прочитаны текстом |
| [System Design: Design YouTube](https://www.youtube.com/watch?v=jWRW2xGMqSw) / [How Does Live Streaming Platform Work?](https://www.youtube.com/watch?v=7AMRfNKwuYo) | 7:13 / 5:25 | кейсы | Медиа-хостинг = `../classic-designs.md` §4; стриминг — расширение |
| [Design a Web Crawler](https://www.youtube.com/watch?v=6u25GckPhLU) / [Design A Location Based Service](https://www.youtube.com/watch?v=M4lR_Va97cQ) | 5:41 / 24:41 | кейсы | Не наши главные кейсы; LBS — единственный длинный mock на канале, глянуть формат |
| [Top 5 Most-Used Deployment Strategies](https://www.youtube.com/watch?v=AWVTKBUnoIg) / [How Big Tech Ships Code to Production](https://www.youtube.com/watch?v=xSPA2yBgDgA) | 10:00 / 4:28 | эксплуатация (KB §10) | Blue-green, canary, rolling — блок «как выкатываем» |

Что на канале есть, но на секцию не нужно: инженерная база ниже уровня секции (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)