title: Конспект материала 30 — system-design-master-plan (mohsenshafiei) source: https://github.com/mohsenshafiei/system-design-master-plan author: Mohsen Shafiei — «Roadmap to Become System Design and Architecture Master»: одна визуальная диаграмма (draw.io), без текстов и ссылок; последнее изменение 07.2024 конспект: подготовлено 2026-09-18, TASK-45.34; исходник карты прочитан целиком (src/roadmap.xml, 156 текстовых узлов), структура восстановлена по координатам и рёбрам; каждая секция сверена с KB / articles / classic-designs статус: P3-источник «после секций», контентного нового нет (95 % тем уже покрыто). Единственное применение до слотов — прогон §2 как трекера самопроверки (15 мин). Это чек-лист, а не учебник: карта не содержит ни одного объяснения или ссылки
Материал 30: system-design-master-plan — roadmap-чек-лист
1. Что это (и что это НЕ)
Репозиторий автора-новичка (один автор, 07.2024): одна диаграмма-дорожная карта «System Design Master Plan» — roadmap-new.svg (текст — кривыми, исходник — src/roadmap.xml draw.io). README — две строки-заглушка. Больше в репо ничего нет: ноль ссылок, ноль объяснений, ноль кейсов.
Структура карты: змейка из ~60 тем в 16 секциях → 30 задач-упражнений → мини-фреймворк прохождения интервью (7 шагов) → «Continue Learning». Ценность для нас — не знания (их нет), а готовый плоский список тем: единственный во всей серии 45.12–45.37 «трекер самопроверки», который можно прогнать за 15 минут и честно отметить, что умеешь назвать с трейдоффом, а что нет.
2. Полная структура карты (что внутри)
2.1 Теория: 16 секций — темы и где они у нас
Легенда: ✅ покрыто и уже в базе; ➕ микро-дополнение одной фразой (см. §3); — не наш жанр/не берём.
| Секция карты | Темы | Где у нас |
|---|---|---|
| System Design Basics | Horizontal vs Vertical scaling, Monolith vs Microservice, HLD vs LLD, Software Decoupling, Logging & Metrics | ✅ articles/03, KB §3, трейдоффы 45.33; ➕ термин «HLD vs LLD» |
| Key Characteristics of Distributed Systems | Resource Sharing, Openness, Concurrency, Scalability, Fault Tolerance, Transparency, Extensibility, Master & Slave | ➕ академические характеристики (Tanenbaum-словарь): transparency/openness/extensibility у нас не названы; остальное ✅ (KB §5–§9) |
| Networks & Protocols | IP, TCP, UDP, HTTP, HTTPS, DNS, REST, RPC | ✅ KB §1.2/§13.1, трейдофф TCP/UDP 45.33, REST vs RPC 45.13 |
| Latency | Metrics & Calculation, Shapes of Data, Sorts & Availability | ✅ KB §1.2, 45.25; «shapes of data» — профиль данных, наш жаргон «read-heavy/денормализация» |
| Throughput | Metrics & Calculation, Scalability | ✅ трейдофф latency/throughput 45.33 |
| Storage | SQL vs NoSQL, Memory Estimation, Sharding & Partitioning, DB Replication, Map-Reduce, ACID | ✅ KB §2–§6; Map-Reduce — DDIA гл. 11 (batch). Память «на салфетке» — KB §2 |
| Availability | Single Point of Failure, Adding Server / Handling Failing Servers | ✅ KB §9, articles/08, Методичка этап 6 |
| Caching | Benefits, In-Memory / Database / Application Caching, Cache Aside, Read Through, Write Through, Write Around, Write Back | ✅ KB §4, articles/06; ➕ «write-around» — единственная не названная у нас стратегия |
| Proxies | Forward Proxy, Reverse Proxy, NGINX, HAProxy | ✅ articles/03, 45.13 (forward vs reverse одной фразой), sdp-guide §4 |
| Consistency | Consistent Hashing, Adding Server | ✅ KB §6, 45.30 (Instagram логические шарды) |
| CAP Theorem | — | ✅ KB §7, Brewer-кейс 45.30 |
| Content Delivery Network | Push CDNs, Pull CDNs | ✅ sdp-guide §4 (push/pull + когда что), articles/03 |
| Load Balancing | Round Robin, Weighted RR, Load-Based Selection, IP Hashing, Path/Service Based, L4/L7, LB for LB, Mixed Bag | ✅ KB §13.2, 45.19 (архитектура LB), 45.31 (GSLB/DNS) |
| Logging and Monitoring | Data Collection → Transport → Storage → Analysis → Alerting | ✅ KB §10, articles/12 (пайплайн телеметрии как цепочка) |
| Rate Limiting | — | ✅ KB §14.1 (алгоритмы), articles/10, 45.13 |
| Polling and Streaming | — | ✅ KB §13.3, articles/10 (WebSocket / long-polling / SSE) |
Итог сверки: из ~60 тем карты не покрыто ничего содержательного; лакуны — 5 микро-фраз (§3).
2.2 Exercises: 30 задач-упражнений (второй слой карты)
Классический пул интервью-задач без tiering и без разборов (только названия). Разбивка по тому, что у нас уже есть:
- Полностью закрыто нашими эталонами/учебниками (14): URL shortener, Twitter, Instagram, WhatsApp/Telegram-чат, YouTube/Netflix-стриминг, Facebook News Feed, API Rate Limiter, Web Crawler, Google Drive/Dropbox (KB §14.5), Uber/Grab (45.13), Booking/Airbnb (отели — мок 45.27), GitHub-класс, Redis KV, Twitter Search (поиск — из автозаполнения/краулера KB §14).
- Есть фундамент, собрать за час (8): Pastebin (≈ shortener), Google Docs/Google Sheet (OT/CRDT — вторая линия 45.31), Tinder, Yelp/Nearby Friends (гео — KB §13.6), Mint.com (финансовый агрегатор — финтек-домен пользователя), WeChat (≈ мессенджер + суперприложение), Deployment System, Multiplayer Card Game (real-time).
- Чужой жанр — LLD, не наш формат секции (6): Questionnaire, Vending Machine, ATM, Traffic Control System, Airline-reservation-класс. Полезны только как «размять сущности и состояния», для секции «крупноблочная схема» смысла нет.
2.3 «Let's Learn How to Solve a Problem» — фреймворк (третий слой карты)
7 шагов: Requirement Clarification → Capacity Estimation (QPS, bandwidth, traffic, storage, read/write ratio) → System API (endpoint'ы, схемы) → Database Schema → High-Level Design → Detailed Design → Removing SPOFs and Bottlenecks.
Это третья независимая фиксация того же кольца, что в нашей методичке (Яндекс-статья → наш §1; Alex Xu «4 шага» → сверка §1; здесь — карта). Совпадение шагов 1:1 с нашими этапами 1–5 (у карты нет отдельного шага эксплуатации — у нас глубже, этап 6 обязателен). Ценность — контрольные вопросы внутри блоков HLD/Detailed Design, которые стоит держать на само-проверке:
- «Should we keep all data of a user in one DB? Why?» — наш критерий выбора шард-ключа (KB §6).
- «How do you handle hot users?» — hot partition → coalescing + consistent-hash routing (готовый ответ есть: Discord, 45.33).
- «What are the cache strategies? Why cache at all?» — этап 4 методички (KB §4).
- «Which components need better load balancing and which policy?» — этап 6.
- «Is there any single point of failure? / Do we have enough replicas? / How are we monitoring?» — этап 6, обязательный финал.
3. Микро-лакуны: 5 фраз, которых у нас нет дословно
- HLD vs LLD (Basics): один термин — «секция про высокоуровневую схему; low-level (классы/интерфейсы) — это другой жанр интервью, мы его не проходим».
- Академические характеристики DS (Tanenbaum-стиль): transparency (прозрачность как цель РС), openness (открытые протоколы), extensibility. Полезны одним предложением в «характеристики распределённой системы» при отказоустойчивости; для секции — опциональный словарь, не тема.
- Write-around cache: пишем в БД, кэш затронут только чтениями; антитеза write-through. Одна строка в кэш-блоке (KB §4/статья 06).
- Forward proxy (против reverse) — уже есть в 45.13: «forward — перед клиентом (анонимизация/контроль доступа), reverse — перед серверами (фасад/SSL/статика)». Зафиксировать в KB §13 при случае.
- «Shapes of data» — переводится в наш жаргон: профиль данных решает схему (read-heavy → денормализация/кэш; write-heavy → LSM-батч; hot rows → партиционирование). У нас этот вывод размазан по KB §3–§6, карта даёт ярлык.
Ни одна из них не требует нового материала: всё закрывается строчкой в уже готовых блоках.
4. Что взять в подготовку
До слотов (15 минут, любой вариант А/Б/В)
Прогон §2.1 как трекер самопроверки — идти по 16 секциям и по каждой теме говорить вслух «что это + трейдофф за 30 секунд». Это репетиция речи, а не чтение: карта ничего не объясняет, зато задаёт порядок и полноту. Слабые места — пересобрать из готовых источников (KB §-напротив), новых материалов не открывать (принцип §4 индекса 45.12).
После секций
- Задачник §2.2 — расширение пула билетов для раундов тренировок: 8 задач «собрать за час» (Google Docs/Sheet, Yelp/Tinder, Mint.com, Deployment System…) — автоматически дают свежий незнакомый контекст, как каты 45.29. Geek-вариант: прогнать одну LLD-задачу (Vending Machine/ATM) как разминку моделирования сущностей.
- Контрольные вопросы §2.3 — добавить в чек-лист self-review рубрики (Методичка §6.2): «все ли данные пользователя в одной БД?», «hot users?», «сколько реплик при падении сервера?» — уже частично есть, карта даёт формулировки.
5. Чего не брать
- Как учебник/подборку — контента нет: 0 ссылок, 0 объяснений. Всё, что карта называет, у нас уже глубже разобрано.
- Секцию Exercises целиком — копирует наш пул; уникальных web-scale задач нет (все наши темы пересекаются: shortener/лента/чат/медиа/гео/поиск).
- LLD-блок и «Continue Learning» — вне формата секции и вне задачи.
- Никакие темы карты не дают повода открыть «новое» до слота — лакуны §3 закрываются одной строкой в готовых блоках.
Связанные документы
learn-system-design-index.md— индекс и приоритеты всей подборки (45.12)../methodology.md§5 — план под слоты А/Б/В; §6.2 — рубрика self-review (сюда уходят контрольные вопросы §2.3)../classic-designs.md— эталоны: URL shortener / лента / мессенджер / медиа (покрывают 14 из 30 задач карты)knowledge-base.md— глубина по каждой секции карты (§-колонка в §2.1)- конспекты соседей серии:
lsd-awesome-scalability.md(45.30),lsd-ashishps1-resources.md(45.33, трейдоффы + Discord — ответ на «hot users»)