title: Конспект материала 12 — блог ByteByteGo (архив статей) source: https://blog.bytebytego.com/archive author: Alex Xu и команда ByteByteGo (Substack) конспект: подготовлено 2026-09-17, TASK-45.16; архив выгружен целиком через API Substack — 744 поста за 2021-11..2026-09 (557 бесплатных, 187 платных); по темам секции отобраны кандидаты, прочитаны полные тексты ~15 статей; выжимки по фактам из текстов, не по заголовкам статус: P2-источник к слотам 21–22.09. Не учебник, а банк реальных кейсов: топ-5 дают прямые аргументы «а как в реальности» для секции, EP-карточки — словарь и референсы для доски. Платная серия перекрывается бесплатным контентом — подписка не нужна

Материал 12: блог ByteByteGo — индекс архива

Блог команды ByteByteGo на Substack: 744 поста с ноября 2021. Это не учебник (роль учебников у нас — SDP, karanpratapsingh, DDIA) и не сборник диаграмм (роль визуального словаря — system-design-101, материал 11). Ценность блога — живые инженерные кейсы (Instagram, Facebook/Memcached, Google Cloud outage, Uber, Tinder): разборы «как это устроено в реальности» с цифрами и трейдоффами — готовые ответы на вопрос интервьюера «а как в настоящих системах?».

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

Важно: у бесплатных постов тело открыто полностью, у платных — только превью (описание + первые абзацы). Ссылки в этом конспекте — на канонические URL постов.

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

1. Прямая релевантность секции: крупноблочная схема сервиса класса инстаграм/твиттер + отказоустойчивость; темы брифа — отказоустойчивость, кэш, шардирование, очереди.
2. Доступность: все топ-5 — бесплатные, прочитаны полностью.
3. Не дублировать уже покрытое: fan-out ленты и гибрид push/pull уже детально разобраны у нас (../classic-designs.md §2, KB §1/§8), поэтому «Design Twitter» (EP5) — во второй эшелон, хотя кейс-то наш.

3. Топ-5 статей

3.1 How Instagram Scaled Its Infrastructure (2025-02-18) — сквозной кейс

Выжимка. Путь от ручного масштабирования (инженеры вручную добавляли серверы перед выходными) до миллиарда пользователей. Масштаб 2017–2018: 400M DAU, 100M медиа-загрузок/день, 4 млрд лайков/день — и каждый лайк это запись в БД. Три измерения масштабирования: (1) scaling out — переезд с AWS в ДЦ Facebook, мульти-ДЦ, LB, отказ от монолитной БД; (2) scaling up — оптимизация запросов, Memcached, горячие функции Python → C++; (3) scaling engineering — continuous deployment 40+ релизов/день, canary-выкаты. Бэкенд: Django (веб-слой) + RabbitMQ (брокер) + Celery (воркеры асинхронных задач с ретраями) — на примере лайка: запись счётчика в PostgreSQL, счётчик читается из Memcached, уведомление уходит через очередь. Хранилища: PostgreSQL (master-replica, критичные транзакции), Cassandra (ленты, логи, eventual consistency), Memcached (профили, счётчики), Haystack (медиа + CDN). Проблемы согласованности: replication lag, инвалидация кэша, кросс-регионная синхронизация. Отдельно — Memcache lease против thundering herd: при cache miss lease-токен получает один сервер, остальные ждут или читают stale.

Что брать на секцию. - Это чек-лист блоков нашей сквозной схемы: веб-слой → очередь+воркеры → SQL + NoSQL + кэш + объектное хранилище/CDN → мульти-ДЦ. Сверять свою доску с этим набором. - Готовые фразы: «селекция хранилищ по требованиям консистентности: SQL для транзакций, Cassandra для лент с eventual», «асинхронщина через очередь: уведомления и медиа-обработка не на критическом пути». - Lease — ответ на вопрос «популярный ключ протух, все бэкенды разом пошли в БД — что делаем?» (KB §4: битые замки/прогрев). - Canary + метрики для блока «эксплуатация» (KB §10): Instagram катит 40+ раз в день именно потому, что выкат маленькими порциями с мониторингом.

3.2 How the Google Cloud Outage Crashed the Internet (2025-06-17) — отказоустойчивость

Выжимка. Разбор глобального инцидента GCP 12.06.2025 (50+ сервисов, 40+ регионов). Цепочка: новый код проверки квот в Service Control (гейт всего API-трафика) вышел без feature flag и без null-check; политика с пустыми полями активировала непротестированный путь → NPE → падение бинаря; скомпрометированная политика реплицировалась глобально через Spanner за секунды — упало сразу везде. Ответ: kill switch («красная кнопка») через 10 минут, откат по регионам за ~40 минут. us-central-1 восстанавливался 2ч40м: массовый рестарт задач без randomized exponential backoff → herd effect → regional Spanner под ударом. Health dashboard и мониторинг лежали вместе с инфраструктурой → час без публичной коммуникации. Уроки Google: валидация данных перед репликацией, обработка кривых входов, безопасный выкат.

Что брать на секцию. Это готовый рассказ «как ломается отказоустойчивость» на все вопросы блока: - SPOF в управляющем слое: система, через которую проходит весь трафик, — самый опасный компонент (наш аналог: API gateway, service discovery). - Blast radius глобальной репликации: репликация «как спроектировано» разносит и баги; нужна валидация/карантин данных. - Feature flag — новый код за флагом, иначе откат = деплой. - Backoff + jitter при массовом рестарте (KB §9: metastable failure) — восстановление само может стать отказом. - Observability не должна зависеть от наблюдаемой системы; деградация по слоям вместо «всё или ничего».

3.3 How Facebook served billions of requests Using Memcached (2024-05-14) — кэш

Выжимка. Memcache = распределённая система, построенная из односерверного Memcached. Два режима: query cache (look-aside / cache-aside: читаем — при миссе тянем из БД и кладём; пишем — обновляем БД и удаляем ключ из кэша, не обновляем) и generic KV (пре-вычисленные результаты ML). Архитектура: регионы (primary + read-only реплики, синхронизация MySQL-репликацией) → внутри региона frontend-кластеры (web + memcache) + storage-кластер. Внутри кластера: consistent hashing; DAG зависимостей ключей → батчинг и параллельный fetch (один запрос страницы = сотни обращений к кэшу); UDP для get (потеря пакета трактуется как cache miss), TCP для delete; mcrouter на каждой веб-машине (роутинг, батчинг, ретраи). Leasing (64-бит токен на ключ, выдаётся на мисс) решает stale sets и thundering herd — пиковая нагрузка на БД 17K → 1.3K q/s. Отказы: локальные — авторемедиация; кластер лёг — трафик в соседние кластеры; Gutter pool (~1% машин) принимает трафик упавших серверов вместо рехеша горячих ключей (20% трафика на одном ключе → рехеш = каскад). Региональная инвалидация: mcsqueal читает commit log БД и рассылает делиты через mcrouter во все кластеры региона. Философия: сознательно допускаем слегка протухшие данные, чтобы не перегрузить бэкенд.

Что брать на секцию. Самый плотный источник по кэшу (KB §4): cache-aside + инвалидация после записи, lease против herd, горячие ключи → отдельный пул, региональные пулы кэша, read-after-write. Цифра 17K→1.3K q/s — готовый аргумент цены lease. Фраза «мы выбираем staleness вместо перегрузки БД» — готовый трейдофф для блока консистентности.

3.4 EP203: RabbitMQ vs Kafka vs Pulsar (2026-02-21) — очереди

Выжимка. Три ментальные модели брокера. RabbitMQ — классический брокер: producer → exchange → queue, push консьюмеру, ack, сообщение удалена; для task distribution и «сделать ровно один раз» (задачи, запросы, workflow). Kafka — не очередь, а распределённый лог: append в партиции, данные живут по retention независимо от потребления, консьюмеры тянут по offsetам и могут проиграть всё заново; для стриминга, аналитики, когда одни и те же события читают несколько команд. Pulsar — гибрид: stateless-брокеры + BookKeeper (durable ledger), позиция через курсоры; storage и compute масштабируются независимо, поддерживает и стриминг, и очередевые паттерны. Вывод автора: выбор — не «что быстрее», а как данные должны течь, как долго жить и сколько раз читаться.

Что брать на секцию. Каркас ответа «какую очередь возьмёте и почему» в кейсе ленты: очередь задач (отправка пушей, медиа-обработка) — брокерная модель; доставка постов в ленты — лог-модель: fan-out воркеры могут упасть и перечитать партицию с офсета, несколько консьюмеров (ленты, счётчики, антифрод) читают один поток событий. Совпадает с нашим выбором Kafka в ../classic-designs.md §2 — этот пост даёт формулировку «почему».

3.5 Vertical partitioning vs horizontal partitioning (2022-02-23) — шардирование

Выжимка. Словарная карточка: вертикальный партишининг — колонки разносим в отдельные таблицы (те же строки, меньше колонок); горизонтальный (шардирование) — строки разносим по отдельным хранилищам (те же колонки, меньше строк). Роутинг: range-based по упорядоченной колонке (ID, timestamp) — просто, но рискует hotspot; hash-based (например, user_id mod N) — равномернее, но теряет порядок. Плюсы: горизонтальное масштабирование, меньше строк на запрос → быстрее. Минусы: order by собирается в приложении из шардов; неравномерное распределение (hotspot).

Что брать на секцию. Минимум по KB §6, чтобы говорить терминами без пауз: шардировать кэш лент и БД по user_id (hash), выбор ключа шардирования = выбор равномерности vs локальности запросов, «селебрити» — классический hotspot, который мы снимаем отдельной стратегией (pull, KB §1). Для глубины по consistent hashing и репликации шардов — второй эшелон (Spanner, Tinder).

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

5. Платная серия (подписка не обязательна)

У ByteByteGo темы «Crash Course» почти полностью перекрыты бесплатными EP-карточками и нашими материалами. Купить подписку ради подготовки к слотам не нужно; таблица — на случай, если подписка уже есть.

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

1. Банк аргументов (кейсы 1–3). По 30–40 минут на чтение; выписать цифры-аргументы: 17K→1.3K q/s (lease), >99.9% hit rate (Uber), 2ч40м восстановления из-за herd (GCP), 40+ релизов/день (Instagram). На секции «а как в реальности?» — это готовые ответы с числами.
2. Сверка сквозной схемы. Перед тренировкой доски пробежать §3.1: все ли блоки (LB, gateway, сервисы, очередь, кэш, SQL/NoSQL, медиа/CDN, мульти-регион, мониторинг) на нашей схеме из ../classic-designs.md §2.
3. Словарь EP-карточек (§4). По 5 минут: RabbitMQ vs Kafka vs Pulsar, Kafka fast, LB vs gateway, шардирование — проговорить вслух своими словами.
4. Чего в блоге нет и куда идти: сквозной фреймворк ответа — ../methodology.md §2; числа для оценок — KB §1–2; эталонные разборы под наш тайминг — ../classic-designs.md; устройство хранения — DDIA-карта (KB §12).

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

• ../knowledge-base.md — §4 (кэш), §5 (репликация), §6 (шардирование), §8 (очереди), §9 (отказоустойчивость), §10 (эксплуатация)
• ../classic-designs.md §2 — наш эталонный разбор ленты (fan-out push/pull, graceful degradation)
• ../methodology.md §5–§6 — план подготовки под слоты и протокол тренировок
• learn-system-design-index.md — индекс подборки (этот материал — №12, P2)
• конспекты соседних материалов: lsd-system-design-101.md (45.15), lsd-bregman-notebook.md (45.14), lsd-karanpratapsingh-system-design.md (45.13)