title: Конспект материала 14 — System Design Newsletter (systemdesign.one) source: https://newsletter.systemdesign.one/ author: Neo Kim (Substack, «The System Design Newsletter») конспект: подготовлено 2026-09-17, TASK-45.18; архив выгружен целиком через API Substack — 173 поста за 2023-05..2026-09 (108 бесплатных); прочитаны полные тексты 13 выпусков-кандидатов + сняты факты ещё с 9; выжимки по фактам из текстов, не по заголовкам статус: P3-источник (до слота 18.09 не открывать). Банк коротких кейсов по 4–8 минут: топ-5 закрывает типовые задачи секции (лента, чат, медиа, пиковые события/отказоустойчивость); URL shortener в архиве представлен только BOE-расчётом (второй эшелон) — эталонный разбор уже есть в yandex-564132.md и ../classic-designs.md

Материал 14: System Design Newsletter — индекс архива

Еженедельная рассылка Neo Kim (systemdesign.one): короткие разборы реальных архитектур в формате «история компании → пронумерованные техники с картинками → ссылки». Это не учебник и не шпаргалка — роль таких у нас закреплена (SDP, karanpratapsingh, DDIA; methodology §7). Ценность — кейсы на 5 минут каждый: удобно как «последняя миля» по конкретной теме перед тренировкой или слотом: прочитал выпуск → перенёс 2–3 приёма в свой разбор.

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

Каждый выпуск — 4–8 минут чтения, 5–13 техник с диаграммами. Автор честно помечает, где разбор основан на исследованиях, а не на первоисточниках («may differ from real-world implementation») — цифры для секции берём только те, что подкреплены его ссылками на инженерные блоги.

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

1. Прямое покрытие типовых задач секции: лента, URL, чат, медиа + отказоустойчивость как ядро нашего этапа 2.
2. Все топ-5 — бесплатные, прочитаны полностью.
3. URL shortener: единственный выпуск по теме — «Back of the Envelope» (BOE-расчёт, 2023-05-07, 1 страница). Эталонный разбор shortener у нас уже есть (yandex-564132.md, ../classic-designs.md §1), поэтому BOE — во второй эшелон как быстрая самопроверка оценок.
4. Чат не дублируем: в топ идёт WhatsApp (классика, сжатая выжимка практик), детальные WeChat и Slack — второй эшелон.

3. Топ-5 выпусков

3.1 How Hashnode Generates Feed at Scale (2024-01-21) — лента

Выжимка. Платформа блогов, 2.3 млн разработчиков. Лента = персональный список статей по подпискам на авторов и теги. Без ML: каждой статье присваивается score по факторам (лайки, просмотры, комментарии — нормализуются ради разнообразия; уже показанному в этой ленте статья понижает ранг ради свежести). Генерация: precompute для активных пользователей (заходивших в последние дни) и складывание в Redis (serverless-провайдер Upstash) — считать всё для всех = жечь память кэша. Архитектура event-driven: AWS EventBridge собирает события (публикация, лайк), генерацию делают Lambda-функции, оркестрация параллельного прекомпута — Step Functions (distributed map). В кэше ленты только ID статей (данные статей — отдельный кэш, на чтении вынимаются одним MGET); вставка статьи в ленты подписчиков — O(n), чтение своей ленты — O(1). Узкое место — знаменитый автор с сотнями тысяч подписчиков: линейная вставка дорогая; решение — merge-on-read: вписывать статью в ленту подписчика в момент его захода.

Что брать на секцию. Самый близкий к нашей ленте разбор: числовая формулировка трейдоффа push/pull — «пишем O(n) на подписчика при публикации vs читаем O(1) своим кэшем»; «селебрити» снимается отложенной вставкой (гибрид push/pull, наш KB §1); precompute только для активных = управление памятью кэша лент; в кэше только ID, сборка карточек отдельным батч-запросом. Совпадает с нашим эталоном (../classic-designs.md §2) — использовать как независимое подтверждение схемы реальным кейсом.

3.2 8 Reasons Why WhatsApp… 32 Engineers (2023-08-27) — чат

Выжимка. 450 млн DAU, 50 млрд сообщений/день, команда 32 инженера (позже куплен Facebook за $19 млрд). Восемь практик: (1) single responsibility — только месседжинг, никаких ads/social, борьба с feature creep; (2) Erlang: легковесные процессы VM вместо OS-потоков → дешёвый context switch, плюс hot loading — деплой кода без рестарта сервера и перелива трафика; (3) не изобретать велосипед: ядро на open-source ejabberd (XMPP-сервер на Erlang) с переписанными частями, push — сторонний; (4) cross-cutting concerns: мониторинг/алертинг, CI/CD; (5) диагональное масштабирование (горизонталь + вертикаль), FreeBSD с тюнингом ядра (файлы/сокеты) до 2M+ соединений на сервер, оверпровижининг под всплески и запас под отказы; (6) flywheel: регулярный цикл «измерить CPU, context switches, syscalls → убрать узкое место»; (7) load testing искусственным прод-трафиком и правками DNS — поиск SPOF до продакшена; (8) маленькая команда: число путей коммуникации растёт квадратично.

Что брать на секцию. Каркас ответа на чат-кейс: длинные соединения, «дешёвые процессы» (Erlang/ejabberd) вместо потока ОС на соединение, 2M соединений/нода — число для прикидки парка серверов; load testing против SPOF — мостик к отказоустойчивости; «команда маленькая → архитектура простая» — аргумент против оверинжиниринга, если интервьюер давит в сторону лишних микросервисов. Детальную внутренность чата (очереди, слои, мульти-ДЦ) брать из WeChat (§4).

3.3 11 Reasons Why YouTube… 9 Engineers (2023-09-16) — медиа (VOD)

Выжимка. 2005 год, серверы в кредит, 100 млн просмотров/день силами 9 инженеров. Ключевое: (1) flywheel — цикл «найти и починить узкое место» вместо дорогого железа; (2) простой проверенный стек: MySQL для метаданных, lighttpd для раздачи видео, Python на приложении (по их замерам никогда не был бутылочным горлышком; CPU-тяжёлое — через C-расширения), Linux-инструменты (strace, vmstat, tcpdump); (3) простота как корень масштабируемости (и быстрые репивоты); (4) choose your battles: популярные видео — на сторонний CDN (мало хопов, из памяти, авторепликация), длинный хвост — свой колокейшн с software RAID; thumbnails (мелкие объекты, 4 на видео) — в BigTable (кластеризация мелких файлов, многоуровневый кэш); счётчик просмотров «фейкался» и обновлялся асинхронно; (5) три столпа: stateless веб-слой → репликация; БД: сначала реплики (replication lag, узкое место записи) → партиционирование (уровень выбран анализом запросов/джойнов/транзакций = пользователь; −30 % железа); (6) 80/20: выделенный кластер под видео-трафик; (7) многоуровневый кэш; (8) jitter на экспайре кэша популярных видео против thundering herd; (9) long game: быстрые хаки покупают время, трейдофф эффективности в пользу масштабируемости (Python вместо C, латентность в обмен на чёткие границы компонентов, раздача по доступной полосе, а не по латентности); (10) адаптация: RPC вместо REST на критичном пути, BSON, eventual/read-your-writes для комментариев, асинхронность некритичных задач.

Что брать на секцию. Полный словарь VOD-кейса: разделение «горячее — CDN / хвост — своё хранилище»; мелкие файлы — в специализированное хранилище, а не в файловую систему; три столпа масштабирования одной фразой; jitter — первый ответ на «популярный ролик разом валит бэкенд» (KB §4: прогрев/битые замки); асинхронный счётчик = eventual consistency с готовой формулировкой цены.

3.4 How Facebook Scaled Live Video to a Billion Users (2024-05-24) — медиа (live)

Выжимка. Стрим 1-ко-многим. Конвейер: вещатель шлёт видео по RTMP (поверх TCP, сплит на аудио/видео) → live stream server транскодит в несколько битрейтов → нарезка на 1-секундные сегменты MPEG-DASH (HTTP-стриминг: manifest с указателями на медиа-файлы, обновляется по мере нарезки). Кейс-пиковая нагрузка: трансляция спасения из пещеры Тхам Луанг, 7.1 млн одновременных зрителей. Масштабирование: пул live stream server'ов, consistent hashing по stream ID → вещатель после обрыва реконнектится на тот же сервер; ABR — качество сегмента подстраивается под полосу зрителя (и upload-полосу вещателя). Латентность: 2-уровневая иерархия edge (ближе к зрителям, по стране; до 200K rps) → origin (по континенту) → live stream server; промах кэша пробивается выше по цепочке. Thundering herd: внутри edge — HTTP proxy + кэш, сегменты размазаны по кэш-серверам; но даже с кэшем ~2 из 100 запросов доходят до origin — на масштабе Facebook это много → request coalescing: конкурентные запросы одного сегмента ставятся в очередь, наружу уходит один запрос, ответ раздаётся всем ждущим; тот же приём повторён на origin. Плюс репликация сегментов между edge-серверами.

Что брать на секцию. Готовая доска live-медиа: RTMP → транскодинг → сегменты + manifest → иерархия кэшей. Три приёма против thundering herd в одном кейсе: jitter (YouTube, §3.3), lease (FB Memcached — ByteByteGo, материал 12), request coalescing («схлопываем конкурентные промахи в один бэкенд-запрос») — самый сильный ответ на вопрос «кэш протух, тысяча запросов полетела в origin — что делаем?». Consistent hashing по stream ID — пример осознанного выбора ключа хеширования под sticky-сессию.

3.5 How Disney+ Hotstar Scaled to 25 Million Concurrent Users (2023-09-17) — пиковые события, отказоустойчивость

Выжимка. Live-крикет, рекорд 25 млн одновременных зрителей (архитектуру готовили к 50 млн). Главное: (1) автоскейлинг сам не спасает — новой ноде до healthy ~90 секунд → prewarming инфраструктуры перед матчем по оценке пика из исторических данных, прогрев совместно с автоскейлингом, серверы на полной мощности; (2) против herd: jitter клиентских запросов, клиентский кэш, exponential backoff; (3) Парето: критичные компоненты — subscription engine, metadata engine, стриминг — им максимальная HA и отдельные твики, остальное — проще; многоуровневая избыточность; (4) многоуровневый кэш с правильными TTL: система работает, даже когда origin умер; TTL каждого уровня мониторят (риск herd и рассинхрона); (5) rate limiting + denial list против подозрительного трафика; (6) panic mode: сервер сообщает клиенту о перегрузе, клиент бэкоффится; в панике — приоритет критичным, graceful degradation некритичных (рекомендации), трафик идёт в обход отключённых компонентов; (7) тесты до события: chaos (живучесть при отказах), performance (flood.io), load (gatling.io); (8) вместо Chef/Puppet — baked container images (нода healthy сразу после провижининга) + Kubernetes; (9) трейдоффы облака: лимит AWS на инстансы одного типа → смешивать типы; нет тонкой настройки автоскейлинга → свой скрипт; (10) flywheel профилирования (подкрутили битрейт для зрителей с узким каналом) + открытый канал по метрикам между всеми стейкхолдерами.

Что брать на секцию. Самый плотный выпуск ровно под нашу тему «отказоустойчивость» этапа 2: «почему недостаточно autoscaler'а» — цифра 90 сек до healthy; panic mode = наш graceful degradation с готовым словарём (favor critical, degrade rest, bypass); rate limit + denial list; мониторинг TTL кэшей как часть консистентности; baked images как ответ «как ускорить ввод ноды в строй»; три вида тестов как блок «как готовимся к пику». Складывается в готовый ответ на «что происходит в момент, когда всех зрителей одновременно пустили внутрь».

4. Второй эшелон (бесплатные, по темам)

5. Платный период и бесплатные рефешеры 2025

Пейвол (с 2025-10): интервью-разборы Design Spotify / WhatsApp / Twitter Timeline / Airbnb / YouTube / ChatGPT / Web Crawler / Stock Exchange и большие dives (Distributed Systems, CDN, Kubernetes). Подписка не нужна: типовые кейсы у нас уже разобраны глубже (../classic-designs.md, конспекты 45.13–45.17), а «114 concepts» и подорожавшие dives дублируют KB.

Бесплатные концептуальные рефешеры 2025 (по 5–10 минут, точечный повтор вслух перед слотом): How Kafka Works (2025-09-25), 5 Rate Limiting Strategies (2025-09-19), Everything About Cache Strategies (2025-06-13), Load Balancing Algorithms (2025-05-19), How API Gateway Works (2025-05-29), API Gateway vs LB vs Reverse Proxy (2025-08-29), Sidecar Pattern (2025-09-18), DNS (2025-05-02), HTTPS (2025-08-07), JWT (2025-05-10). Из ранних карточек: Consistency Patterns (2023-07-25 — strong/eventual/weak в двух абзацах), Gossip Protocol, Hinted Handoff, Service Discovery, Redis Use Cases (2024-06-20 — 8 ролей Redis в одном приложении).

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

1. Не открывать до слота 18.09 — план подготовки (../methodology.md §5) этого не требует; источник P3.
2. Перед 21–22.09: по одному выпуску под вероятную тему кейса — лента → §3.1 (10 мин), чат → §3.2 + WeChat из §4 (20 мин), медиа → §3.3 + §3.4 (20 мин). Выписать себе 2–3 числа: 2M соединений/сервер (WhatsApp), 7.1M одновременных зрителей и 2/100 промахов до origin (FB Live), 90 сек до healthy (Hotstar), −30 % железа от партиционирования (YouTube).
3. Перед тренировкой доски: пробежать §3.4/§3.5 как чек-лист отказоустойчивости: jitter, coalescing, prewarm, panic mode, rate limit + denial list, тесты. Если приём не всплывает в твоём рассказе сам — это пробел.
4. Чего в рассылке нет: сквозного фреймворка ответа (../methodology.md §2), эталонных расчётов (KB §1–2), глубины устройства хранения (DDIA-карта, KB §12). Рассылка — последний слой поверх базы, а не замена.

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

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