---
title: Конспект материала 20 — System Design Blueprint: The Ultimate Guide (инфографика)
source: system-design-guide.jpeg из репозитория learn-system-design; первоисточник — пост ByteByteGo EP56 (blog.bytebytego.com/p/ep56-system-design-blueprint-the), автор схемы Love Sharma; продажа постера — zonito.gumroad.com/l/systemdesignblueprint
author: Love Sharma (схема), Alex Xu / ByteByteGo (публикация), Е. Козлов (в подборке learn-system-design)
конспект: подготовлено 2026-09-17, TASK-45.24; текст снят tiled-OCR (tesseract, сетка 4×4 + точечные кропы, апскейл ×4–6), структура сверена с постом ByteByteGo EP56
статус: полная послойная расшифровка инфографики «весь дизайн на одном листе» (1400×1488). 80 % блоков уже покрыто KB §3–§11 и classic-designs; выжимка для секции — KB §13 (карта «блок → где в KB»). Этот файл — эталонная расшифровка для самопроверки по картинке и источник формулировок. Использовать как визуальный конспект за 10 минут до слота
---

# Материал 20: System Design Blueprint — The Ultimate Guide (инфографика)

Один лист, на котором нарисован **полный путь запроса через систему**: DNS → балансировщик → API-шлюз → фронтенды/CDN → бэкенды → загрузка медиа (чанки, очереди, воркеры) → БД/кэш, плюс сквозные темы слева (распределённые ID, локи, конкурентность) и общий fan-out внизу (уведомления, рекомендации, аналитика, поиск, платежи). Это не учебник, а **карта-шпаргалка**: перед секцией полезно пробежать глазами и проверить, что каждый блок умеешь назвать и объяснить трейдофф.

Происхождение: схема Love Sharma, опубликована ByteByteGo (EP56, апрель 2023) как «шаблон для прохождения system design интервью». В подборке learn-system-design лежит как третья шпаргалка (после LeetCode-шаблона и гиста vasanthk). Отличие от тех двух: здесь не процесс ответа, а **инвентарь системы** — что вообще бывает в дизайн-ответе.

Как читать расшифровку: блоки идут в порядке следования запроса по листу (слева направо, сверху вниз). Курсивом — служебные подписи листа, у списков сохранена оригинальная формулировка (перевод + английский термин). Маппинг на наши материалы — в конце каждого блока. Низкоуверенные фрагменты OCR помечены «(?)».

---

## 1. DNS — резолв домена (верхний левый угол)

Клиент (App / User) спрашивает у DNS «домен → IP?». Цепочка из трёх шагов (номера на листе):

1. **Root Nameserver (RN)** — корневой сервер: «кто отвечает за `.com`?»
2. **Top Level Domain Nameserver (TLD NS)** — сервер зоны `.com`: «кто авторитетный для `amazon.com`?»
3. **Authoritative Nameserver (ANS)** — авторитетный NS домена: отдаёт **IP записи**, здесь `12.23.34.45`

Между ними ходит **DNS Resolver** (рекурсивный резолвер, порт **:53**). Пример листа: `amazon.com` → `TLD NS of .com` → `ANS's IP`.

Хэштеги-подсказки листа: `#GeoDNS` (гео-резолв в ближайший регион), `#Root`, `#ISP` (резолвер провайдера), `#LocalCache` (кэш ОС/браузера/резолвера с TTL), `#MultipleIPs` (домен → несколько IP — простейшая балансировка).

→ KB §13.1. На секции: «клиент резолвит домен через рекурсивный resolver: root → TLD → authoritative; каждый уровень кэшируется с TTL; GeoDNS ведёт в ближайший регион».

## 2. Load Balancer + Options / Algo (верх, левее центра)

Узел **Load Balancer** — первый вход после DNS. Рядом панель **Options / Algo** (алгоритмы выбора ноды):

- **Round Robin** — дефолт для stateless-пула
- **Weighted Round Robin** — ноды разной мощности
- **Least Connections** — для долгих соединений (websocket/streaming)
- **Number of Requests** / **Active Connections** — метрики, по которым алгоритм выбирает
- **Hash / Server Stickiness** — сессии и кэш-локальность (с consistent hashing — ответ про масштабирование пула)
- **Random** — называем, но не выбираем

→ KB §13.2. Обязательная фраза: «перед LB — health checks, нездоровая нода выпадает из ротации».

## 3. API Gateway — контракт на входе (центр, верх)

Самый насыщенный блок листа. Четыре панели:

**Request (что шлюз делает с запросом):**
- Input Validation, Request Header Validations
- Authorization / Authentication (**OAuth 2.0**)
- Rate Limiting / Throttling
- Whitelist / Blacklisting
- Flow Control
- TLS Termination
- Request Deduplication (**idempotent key**)
- Metering / Usage Data Collection
- Request Dispatching
- *…many more*

**Response (что кладёт в ответ):** Gzip / deflate (компрессия), Request ID (трассировка), Pagination, Expiry Headers (кэш-контроль), Mime, Cookie, Error Codes / Message.

**Metrics:** 4XX / 5XX / 2XX, Response Time, Failed Status Codes.

**Наблюдаемость шлюза:** Access Logs, Status Codes, Number of Requests.

→ KB §9 (эксплуатация) + §13.7 (security) + §7 (идемпотентность). На секции называем 4–5 пунктов запросной стороны и 2–3 ответной — этого достаточно.

## 4. Frontend Servers + CDN + real-time транспорт (правый верх)

**Frontend Servers** — фронтенд-тир: `#inMemoryConnections` — карта «User | Connection» в памяти (пример листа: `user_1 | ada_inst_obj…`), через которую фронтенды **Dispatch Messages to other FE Servers** (рассылка между нодами для чата/живых обновлений; рядом — Dispatcher). Для стриминга/чата — отдача **Static / Stream with ABR** (адаптивный битрейт). Панель ресурсов сервера (у обоих тиров, фронтенда и бэкенда): CPU, Memory, Latency, Bandwidth, **Disk I/O (if buffering)** + **Vertical Scale / Horizontal** (наращиваем ресурсы одной машины или число машин).

**CDN / Edge Servers** — `#Global #Regional #Static`:
- Static Content с края
- **Push Hot Resource** — горячее проталкиваем на край заранее
- **Pull Rare Resource** — редкое тянут по промаху
- **Hybrid** — комбинируем
- Учёт края: Cache Miss Outs, Active Resources, Total Resources

**Real-time транспорт** (панель выбора между фронтендом и клиентом): **RTMP** (ingest видео), **WebRTC** (P2P, звонки), **Websocket** (дуплекс), **SSE** (сервер → клиент), **HTTP Short Polling**, **HTTP Long Polling**, **Webhook** (сервер → сервер), **Stream API**.

→ KB §13.3 (таблица выбора транспорта), §4 (CDN-кэш), classic-designs §3 (мессенджер) и §4 (медиа).

## 5. Backend Servers (центр)

`#ClusterOfServers`, `#MicroService`; та же панель ресурсов, что у фронтенда (CPU, Memory, Latency, Bandwidth, Disk I/O, Vertical/Horizontal scale). Держатся вместе **Heartbeat**-ами. Топологии из блока «SERVICES TO SCALE SYSTEM» (см. §6): leaderless (gossip), leader + followers, multi-leaders. Загрузка медиа — через **Upload Object via Signed URL** (подписанные ссылки на приватные объекты, KB §13.7).

## 6. SERVICES TO SCALE SYSTEM — сквозные сервисы (левая колонка)

**Distributed ID Generator Service** (генерация уникальных ID):
- **UUID** — без координации, 128 бит, без порядка
- **Auto Increment** — просто, одна нода, точка отказа
- **Auto Incr. Multiple Servers (Odd / Even)** — чёт/нечёт по нодам: без координации, но плохо масштабируется
- **Twitter's Snowflakes** — 64 бита: время + ID ноды + секвенция
- **Baidu UID generator**, **Sonyflake** — семейство snowflake
- **Offline Generations** — выдача диапазонов заранее (генератор не нужен на критическом пути)

**Distributed Resource Locking** (координация):
- **Redlock (Redis)** — быстро, компромиссы надёжности
- **Google Chubby** — кворумный лок-сервис Google
- **Apache Zookeeper** — кворумная координация (ZAB)

**Concurrency** (управление параллелизмом):
- **Serially** — строго последовательно
- **Serially Batch** — последовательными батчами
- **Pessimistic Locking** — лочим заранее, короткие критические секции
- **Optimistic Locking** — версия/CAS, ретрай при конфликте — дефолт

→ KB §13.4 (ID), §13.5 (локи и fencing token), §7 (идемпотентность).

## 7. UPLOAD VIDEO / IMAGE — пайплайн загрузки медиа (центр листа)

Единственный «сквозной кейс» листа — как загружается видео/картинка:

1. **Upload Object via Signed URL** — клиент пишет напрямую в **Object Storage** (`#S3 #Chunk #Raw`), минуя бэкенд
2. **STREAMING CHUNK METADATA TABLE** — метаданные чанков: `Key | Checksum | Timestamp` (пример: `chunk_1 | asdf23dsf3oj23098asdf3 | 132873423`), `InMemory Key Storage`; **Validate → Checksum** — проверка целостности при чтении; *Sync Centrally* — централизованная синхронизация таблицы
3. **Fan Out: For every new Chunk Object** — каждое событие нового чанка уходит в **Message Queue / Pub/Sub Queue**
4. **Processing Workers** — обработка (транскодинг, валидация): Validate Checksum; метрики: Compute Time, Failed Count, CPU / Disk etc., Encoded / Compression Ratio (?), Storage Consumed, Object Count
5. Готовые объекты — `Obj[0] | Obj[1] | Obj[2] | Obj[3] …`

**Метрики очередей** (панель рядом): Count of messages, Consumption Rate, **In-Transit (Waiting for Ack)**, Queue limit.

→ classic-designs §4 (медиа-хостинг — тот же пайплайн словами), KB §8 (очереди, лаг).

## 8. CACHE (левый низ)

**Метрики:** No. of items, Cache Miss & Hit, Disk & Memory Usage.

**Стратегии записи:** **Write-Through** (кэш+БД сразу: чтение чистое, запись медленная), **Read-Through**, **Write-Around** (мимо кэша в БД), **Write-Back** (кэш сейчас, БД потом; риск потери).

**Eviction:** LRU (Least Recently Used), LFU (Least Frequently Used), FIFO, MRU, Random Eviction, Least Used, On-Demand Expiration, Garbage Collector.

**Distributed Cache** — отдельная нода-картинка с двумя колонками: **Cache Eviction** и **Cache Invalidation** (выселение ≠ инвалидация: первое — нехватка памяти, второе — изменение данных), *Sync Centrally*.

→ KB §4 (полностью: aside/through/behind, stampede, прогрев).

## 9. DATABASE (нижний левый угол)

Четыре колонки:

**Типы БД:** RDBMS, **Column Wide** (wide-column: Cassandra/HBase), **Document**, **Key-Value**, **Graph**, **QuadTree** (пространственные данные — карты/«ближайшие N»), **Time-series**.

**DB Security:** **RBAC** (Role Based Access Control), **Data Encryption**, **Audit Trail**.

**DB Metrics:** Query response time, CPU / Disk Usage, Network Throughput, Active Connections, Storage.

**DB Sharding:** **Consistent Hashing** (минимум перемещений при ресайзе пула), **Mod Hashing / Bloom Filter**, Range based, Hash based, **Geographical** (GDPR, латентность), Directory based (lookup-сервис).

**Репликация/консистентность** (мини-блок справа от шардирования): **Quorum (Read / Write)** (W+R>N — чтение видит последнюю запись), **Hinted Handoff** (временный узел при недоступном реплике), **Merkle Tree** (быстрая сверка/анти-энтропия деревьев данных).

→ KB §3 (критерии выбора), §5 (репликация), §6 (шардирование), §7 (кворумы), §13.6 (гео).

## 10. COMMON FAN-OUT SERVICES (нижний правый угол)

Куда расходятся события из очередей — типовые потребители любого дизайна:

- **Search Service** — `#index` (инвертированный индекс)
- **Notification Service** — забота о шуме: ~Spamming, ~Stop Words, ~Dedup, ~**Retry with Idempotent Key**
- **Recommendation Service** — Filtering: **Content-Based**, **Collaborative**
- **Analytics Service** — события в аналитику
- **Payment Service → Charge Service with Idempotent Key → Third-Party Banking Service** — доменные ошибки банка как обрабатываемые ветки: Expired / Blocked / Invalid Card, Service Down, Insufficient Balance

→ KB §13.7 (платежи и security), classic-designs §2 (лента — fan-out on write/read).

---

## 11. Маппинг на наши материалы и ценность для секции

| Блок листа | Где у нас разобрано | Новое для KB (внесено) |
|---|---|---|
| DNS (root→TLD→ANS, GeoDNS) | KB §13.1 | — (было внесено в 45.12) |
| LB-алгоритмы | KB §13.2 | — |
| API Gateway (req/resp/metrics/logs) | KB §9, §13.7 | списки полей req/resp (§13.8) |
| FE servers, in-memory connections | classic-designs §3 | — |
| CDN (push/pull/hybrid, miss outs) | KB §4 (CDN-кэш), §13 | push hot / pull rare (§13.8) |
| Real-time транспорт | KB §13.3 | — |
| Distributed ID | KB §13.4 | offline generations (§13.8) |
| Локи/координация, конкурентность | KB §13.5, §7 | serially batch (§13.8) |
| Upload-пайплайн (чанки, checksum, MQ) | classic-designs §4 | metadata-таблица чанков (§13.8) |
| Cache | KB §4 | eviction-список листа сверен |
| Database + quorum/hinted/merkle | KB §3, §5–§7 | — |
| Fan-out services | KB §13.7 | recommendation-фильтры (§13.8) |

**Как использовать перед секцией (10 минут):** пройти глазами маршрут запроса по листу 1→10 и на каждом блоке спросить себя «умею ли я это назвать и назвать трейдофф?». Провал = точечное повторение по ссылке из третьей колонки. Печатать сам лист не нужно: наша печатная карточка — `../methodology.md` §7 + KB §1.2/§11 (решение по шпаргалкам — TASK-45.23).

## 12. Отличия от двух других шпаргалок подборки

- **LeetCode Template (45.22)** — *процесс* ответа: что говорить в первые 5 минут, тайминг этапов.
- **vasanthk Cheatsheet (45.23)** — *процесс + таксономии* первого поколения (слои кэша, типы LB).
- **Этот лист** — *инвентарь системы*: полный набор компонентов, которые вообще стоит назвать в дизайн-ответе. Не заменяет первые два, а достраивает: если процесс — «как говорить», то blueprint — «что называть».

Полезное перекрытие с брифом Яндекса: крупноблочная схема (этап 3) = блоки 1–5 листа; детали (этап 4) = блоки 6–9; эксплуатация (этап 6) = метрики-панели каждого блока (у листа они развешаны по всем узлам — это его главная фишка: **метрики привязаны к компонентам**, а не свалены в конец).