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

| Формат | Что это | Доля | Ценность для нас |
|---|---|---|---|
| **Deep-dive разборы** | Пересказ инженерных блогов/пейперсов (Instagram, Facebook, Google, Uber, Netflix…) с диаграммами и анализом. Часть бесплатна, часть — `only_paid` | ~40% постов | **Ядро**: банк аргументов для секции |
| **Weekly refresher (EP-номера)** | Еженедельная рассылка: 3–6 коротких карточек-диаграмм (RabbitMQ vs Kafka, cache-aside, API gateway…) | ~50% постов | Словарь концептов + референсы для доски, по 5 минут на карточку |
| **Платная серия «A Crash Course in…» / «A Guide to…»** | Систематические туториалы по кэшу, Redis, шардированию, rate limiting, HA | ~10% (187 постов) | Перекрывается бесплатным (§5) — подписка не обязательна |

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

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

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

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

| # | Статья | Дата | Тема | KB |
|---|---|---|---|---|
| 1 | [How Instagram Scaled Its Infrastructure To Support a Billion Users](https://blog.bytebytego.com/p/how-instagram-scaled-its-infrastructure) | 2025-02-18 | сквозной кейс секции | §4, §5, §8, §9 |
| 2 | [How the Google Cloud Outage Crashed the Internet](https://blog.bytebytego.com/p/how-the-google-cloud-outage-crashed) | 2025-06-17 | отказоустойчивость | §9, §10 |
| 3 | [How Facebook served billions of requests per second Using Memcached](https://blog.bytebytego.com/p/how-facebook-served-billions-of-requests) | 2024-05-14 | кэш на масштабе | §4 |
| 4 | [EP203: RabbitMQ vs Kafka vs Pulsar](https://blog.bytebytego.com/p/ep203-rabbitmq-vs-kafka-vs-pulsar) | 2026-02-21 | очереди: выбор брокера | §8 |
| 5 | [Vertical partitioning vs horizontal partitioning](https://blog.bytebytego.com/p/vertical-partitioning-vs-horizontal) | 2022-02-23 | шардирование: словарь и трейдоффы | §6 |

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

| Статья | Дата | Тема | Зачем |
|---|---|---|---|
| [EP5: Interview question: Design Twitter](https://blog.bytebytego.com/p/interview-question-design-twitter) | 2022-04-29 | кейс твиттера | Жизнь твита: Write API → **Fanout service** → Redis → Timeline service (по tech talk Twitter 2013). У нас fan-out уже разобран глубже (classic-designs §2) — использовать как сверку схемы и терминов. В том же номере: выбор БД по типу данных, unique ID generator (64-bit, сортировка по времени) |
| [EP33: Twitter Architecture 2022 vs 2012](https://blog.bytebytego.com/p/twitter-architecture-2022-vs-2012) | 2022-11-19 | кейс твиттера | Эволюция архитектуры: как менялись fan-out и хранение лент — аргумент «дизайн эволюционирует с нагрузкой» |
| [How Google Spanner Powers Trillions of Rows with 5 Nines Availability](https://blog.bytebytego.com/p/how-google-spanner-powers-trillions) | 2025-02-04 | репликация/консистентность | Paxos-группы на сплиты, лидер + фолловеры-чтение, TrueTime (GPS+атомные часы), tablets/splits с динамическим решардингом, мульти-зонность. Глубина по KB §5/§7/§9 — 5 nines именно тут |
| [How Uber Serves over 150 Million Reads per Second from Integrated Cache](https://blog.bytebytego.com/p/how-uber-serves-over-150-million) | 2026-01-14 | кэш | CacheFront: Redis перед MySQL (Docstore), hit rate >99.9%, консистентность кэша через CDC-инвалидацию; свежее дополнение к FB-кейсу (альтернатива lease — строгая инвалидация по changelog) |
| [Why is Kafka fast?](https://blog.bytebytego.com/p/why-is-kafka-fast) | 2022-03-23 | очереди: внутренности | Sequential I/O + **zero-copy (sendfile)**: копирование диск→сеть минует приложение, экономия ~65% — готовый deep-dive «почему лог такой быстрый» |
| [Facebook's Database Handling Billions of Messages (Cassandra Deep Dive)](https://blog.bytebytego.com/p/facebooks-database-handling-billions) | 2025-03-11 | хранилища | Cassandra = Dynamo (peer-to-peer, no SPOF) + Bigtable (колонки); модель данных, API из трёх операций; почтовая модель inbox'а — параллель нашей ленте |
| [How Facebook Live Scaled to a Billion Users](https://blog.bytebytego.com/p/how-facebook-live-scaled-to-a-billion) | 2025-05-20 | event-driven медиа | Чанкованные upload'ы с ретраями, параллельное кодирование, обработка хаоса пиков; пример «масштаб как ограничение, не как фича» |
| [How Tinder Recommends To 75 Million Users with Geosharding](https://blog.bytebytego.com/p/how-tinder-recommends-to-75-million) | 2024-12-10 | шардирование | Геошардирование вместо одного глобального индекса: меньше нерелевантных данных, ниже латентность, дешевле; кейс «шардирование по доменному признаку» |
| [High Performance Rate Limiting at Databricks](https://blog.bytebytego.com/p/high-performance-rate-limiting-at) | 2026-05-13 | отказоустойчивость | Rate limiter с Redis на критическом пути = SPOF + 2 сетевых хопа (p99 10–20 мс); редизайн: trade точности за скорость, локальные счётчики; аргумент «что убираем с критического пути» |
| [EP122: API Gateway 101](https://blog.bytebytego.com/p/ep122-api-gateway-101) / [EP123: What is a Load Balancer?](https://blog.bytebytego.com/p/ep123-what-is-a-load-balancer) | 2024-07-27 / 2024-08-03 | сквозная схема | Карточки-референсы для доски: границы ответственности LB vs gateway — частый уточняющий вопрос секции |

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

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

| Серия (платно) | Темы | Чем закрыто бесплатно у нас |
|---|---|---|
| A Crash Course in Caching, ч. 1–3 (2023-03) | Стратегии, инвалидация, паттерны | §3.3 этого конспекта + `lsd-system-design-101.md` (29 гайдов кэш-категории) + KB §4 |
| A Crash Course in Redis (2023-09), Redis Can Do More Than Caching (2023-10) | Устройство Redis, не-кэш use cases | EP-карточки Redis + KB §4 |
| A Guide to Database Sharding (+ Key Strategies), Crash Course in Database Sharding, Consistent Hashing 101 | Алгоритмы шардирования, consistent hashing | KB §6 + §13 (счисление consistent hashing в Blueprint) |
| How do We Design for High Availability? (2024-02), Top Strategies to Build HA Systems (2025-11) | HA-стратегии | KB §9 + Spanner-разбор (§4 этого конспекта) |
| Rate Limiting Fundamentals (2023-05), A Guide to Rate Limiting Strategies (2025-09) | Алгоритмы rate limiting | Databricks-разбор (§4) + KB §9/§13 |
| How to Choose a Message Queue? Kafka vs RabbitMQ (2023-08), Message Brokers 101 (2026-01), Event-Driven Architectural Patterns (2024-10) | Выбор брокера, delivery semantics, EDA-паттерны | EP203 (§3.4) + KB §8 + DDIA 2-е изд. (гл. 11–12) |

## 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)