title: Конспект материала 19 — System Design Cheatsheet (gist vasanthk) source: https://gist.github.com/vasanthk/485d1c25737e8e72759f author: Vasanth Kumar (vasanthk); компиляция из hiredintech, lecloud (Scalability for Dummies), lethain.com, horicky (Scalable System Design Patterns), aosabook — ссылки указаны в самом гисте конспект: подготовлено 2026-09-17, TASK-45.23; текст снят целиком (raw-URL gist, ~150 строк) статус: классическая шпаргалка «первого поколения» (в основе статьи 2010–2014 гг.): 5 шагов процесса, 6 тем самопроверки, веб/фронтенд-чеклисты. Процесс и компоненты у нас уже закрыты (../knowledge-base.md, ../methodology.md §1–§7); уникальное — таксономия кэша по слоям, три типа LB, самопроверка key topics и «platform layer». Рекомендация «что печатать» — ../methodology.md §7 (конец раздела)

Материал 19: System Design Cheatsheet (gist vasanthk)

Одностраничная шпаргалка «всё о дизайне систем на одном листе»: пять шагов процесса, шесть тем для самопроверки знаний, чек-лист веб-приложения и фронтенд-архитектуры. Это самый ранний слой нашей подборки — компиляция статей, на которых выросли System Design Primer и все современные гайды. Для нас ценность не в процессе (формат закрыт Яндексом, ../methodology.md §1) и не в глубине (закрыта KB), а в трёх компактных таксономиях, которых нет в наших материалах: кэш по слоям, типы балансировщиков по реализации, зоны самопроверки.

Позиция в треке: индекс learn-system-design-index.md ставит материал в P1, слот 18.09 (15 мин). Эпиграф гиста задаёт тон всей секции: «Picking the right architecture = Picking the right battles + Managing trade-offs» — выбор архитектуры = выбор битв + управление трейдоффами.

1. Basic Steps — 5 шагов процесса (перевод, сжато)

1. Clarify and agree on the scope — юзкейсы (кто, как пользуется), ограничения: трафик и данные на масштабе (RPS, типы запросов, запись/чтение в секунду), спец-требования (многопоточность, read/write-ориентированность).
2. High level architecture (abstract design) — крупные компоненты и связи, без деталей: application service layer + data storage layer; типовой каркас: webserver (load balancer) → service (partition) → database (master/slave cluster) → caching.
3. Component design — компоненты + конкретные API; OOD-приёмы (фича → модуль; singleton/composition/inheritance); схема БД.
4. Understanding bottlenecks — три вопроса: нужен ли LB и ферма машин; не придётся ли резать БД по машинам и какие минусы это принесёт; не слишком ли медленная БД, чтобы обойтись без in-memory кэша.
5. Scaling — самый мясистый раздел (по сути пересказ lethain «Intro to Architecting Systems for Scale»): - Vertical vs horizontal — мощность машины vs число машин. - Caching — см. §2 ниже (уникальная таксономия). - Load balancing — «публичные серверы спрятаны за балансировщиком»; типы: см. §2. - Database replication — электронное копирование данных между серверами БД, чтобы все видели один уровень информации. - Database partitioning — декомпозиция таблиц по строкам (горизонтально) или по колонкам (вертикально). - Map-Reduce — когда ad-hoc SQL перестаёт масштабироваться (данные/write-load уже требуют шардирования, аналитика требует dedicated slaves) — отдельный слой для data/processing-intensive операций: соцграф, отчёты. Примеры: Hadoop, Hive, HBase. - Platform layer (Services) — выделить платформу из веб-приложения: (а) независимое масштабирование кусков (новый API — добавляем платформенные серверы, не раздувая веб-тир); (б) переиспользование инфраструктуры для нескольких продуктов/интерфейсов (web, API, mobile-приложение) без дублирования бойлерплейпа вокруг кэшей и БД.

Шаги 1–4 ≈ наши этапы 1–5 (../methodology.md §1); эксплуатации (наш этап 6) в гисте нет — тот же пробел, что у LeetCode-шаблона.

2. Уникальные таксономии (чего нет в KB)

2.1 Кэш по слоям: application → database → in-memory

KB §4 говорит о стратегиях работы с кэшем (aside/through/behind, инвалидация, stampede), гист разводит слои, где кэш живёт:

Плюс три стратегии применения (из lecloud): предрасчёт результатов (число визитов за вчера посчитано заранее), предгенерация дорогих индексов (стори-подборки по истории кликов), копии горячих данных в быстрый бэкенд (Memcache вместо PostgreSQL). Перекликается с нашим refresh-ahead/прогревом (KB §4), но сформулировано как «что именно кладём в кэш, когда вычисление дороже чтения».

2.2 Типы балансировщиков по реализации

KB §13.2 закрывает алгоритмы выбора бэкенда (RR, least connections, hash/sticky), гист добавляет классификацию по реализации:

• Smart client — балансировка на стороне приложения; «трудно сделать идеально» (retry, health check, консистентность пулов — свои грабли).
• Hardware LB — железо: $$$, но максимально надёжно.
• Software LB — гибрид, «работает для большинства систем» (nginx, HAProxy, Envoy).

На секции: «software LB перед тиром — дефолт; smart client как дополнение для in-process discovery; hardware — когда бюджет и SLA экстремальны».

2.3 Key topics — самопроверка зон знаний

Шесть вопросов «понимаете ли вы…» — готовый чек-лист «где могут копнуть» перед секцией:

1. Concurrency — потоки, deadlock, starvation; параллелизация алгоритмов; consistency и coherence.
2. Networking — IPC и TCP/IP примерно; throughput vs latency и когда какой фактор релевантен.
3. Abstraction — на чём строим: как работают ОС, файловая система, БД; уровни кэша в современной ОС.
4. Real-world performance — скорость всего, что умеет компьютер: RAM vs disk vs SSD vs сеть (наш KB §1.2).
5. Estimation — back-of-envelope сужает список решений до осуществимых, остаются единичные прототипы/микробенчмарки.
6. Availability & Reliability — как падает, особенно в распределёнке; дизайн под сетевые отказы; durability.

Для нас: пункты 1, 3 — зоны, где Ruby/Rails-бэкграунд слабее системного; перед секцией 21–22.09 по ним можно точечно освежить лексику.

3. Web App considerations + Front-end architecture (что НЕ берём)

Чек-лист «веб-приложение»: Security (CORS), CDN (гео-распределение выдачи + защита от всплесков), Full-text search (Sphinx/Lucene/Solr — ищут по индексу, не по тексту), offline/Service Workers, Web Workers, SSR, lazy load, минимизация запросов (HTTP/2, бандлы/спрайты), тулинг, accessibility, i18n, responsive, браузерная совместимость.

Раздел «Working Components of Front-end Architecture» — код (HTML5/WAI-ARIA, CSS/Sass-стандарты, JS-фреймворки, asset delivery), документация (стильгайд, диаграммы), тестирование (перформанс, visual regression, unit, E2E), процесс (git, зависимости, сборка, деплой, CI).

Для бэкенд-секции Яндекса оба раздела — не наш контур. Что оттуда всё же выносим на этап 4 «периферия меню»: CDN (уже KB §4/§13.1), инвертированный индекс полнотекстового поиска (уже KB §3), CORS/security одним блоком (KB §13.7). Остальное — честно пропускаем.

4. Маппинг на 6 этапов Яндекса

5. Ссылки гиста (куда ведут источники)

hiredintech (system design курс), lecloud «Scalability for Dummies», lethain «Introduction to Architecting Systems for Scale» (источник раздела Scaling), horicky «Scalable System Design Patterns» (картинная классификация паттернов), aosabook «Scalable Web Architecture and Distributed Systems», stackexchange-ответ о scalable web, «how web works» того же автора. Отдельно читать их до секции не нужно: всё покрытие уже лежит в SDP-гайде (45.7), KB и DDIA-карте.

6. Итог: что взять, что печатать

Взять в карточку §7 (внесено, см. ../methodology.md §7, этап 4): слои кэша application → database → in-memory рядом с паттернами кэша; типы LB (smart client / hardware / software) рядом с L4/L7.

Печатать отдельно — нет. Решение «что печатать и держать перед собой на интервью»: один лист А4 с двух сторон — лицевая сторона карточка §7 (позвоночник 6 этапов + чек-листы), оборот KB §1.2 (латентность) + KB §11 (мини-шпаргалка «что назвать»). Обоснование и полная рекомендация — ../methodology.md §7, блок «Что печатать на секцию».