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. Маппинг на наши материалы и ценность для секции

Как использовать перед секцией (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) = метрики-панели каждого блока (у листа они развешаны по всем узлам — это его главная фишка: метрики привязаны к компонентам, а не свалены в конец).