--- title: Конспект материала 18 — My System Design Template (LeetCode discuss 229177) source: https://leetcode.com/discuss/career/229177/My-System-Design-Template author: topcat (LeetCode), май 2019 (по датам первых комментариев); 510+ апвоутов, 67 комментариев конспект: подготовлено 2026-09-18, TASK-45.22; текст снят через reader (страница за Cloudflare); адаптированная карточка по этому шаблону внесена в ../methodology.md §7 статус: самая компактная структура секции «что делать по минутам». Формат и этапы у нас уже закрыты Яндексом (../methodology.md §1); уникальное здесь — чек-листы шагов, меню компонент deep dive и послойный justify. Карточка для секции — ../methodology.md §7 --- # Материал 18: My System Design Template (LeetCode 229177) Одностраничный шаблон проведения System Design Interview от кандидата с LeetCode: шесть шагов с таймингом и чек-листами внутри каждого. Заявленное назначение — «держать перед глазами на интервью». Для нас это третий взгляд на формат (после Яндекса и Поломодова) и готовый скелет карточки-памятки: адаптация под 6 этапов Яндекса — `../methodology.md` §7, этот конспект — источник и обоснование маппинга. Позиция в треке: индекс `learn-system-design-index.md` ставит материал в **P1**, слот 18.09 (15 мин вечером, держать перед глазами на секции). --- ## 1. Оригинальный шаблон (перевод, структура сохранена) Тайминги шаблона в сумме дают ~40–50 минут — на часовой формат Яндекса масштабируем (см. §3). ### Шаг 1. Feature expectations [5 мин] 1. Use cases (сценарии использования) 2. Scenarios that will not be covered — **что в скоуп НЕ входит** 3. Кто будет пользоваться 4. Сколько будут пользоваться 5. Usage patterns — паттерны использования (пики, привычки) ### Шаг 2. Estimations [5 мин] 1. Throughput — QPS на чтение и запись 2. Latency, ожидаемая от системы (чтение и запись) 3. Read/Write ratio 4. Traffic estimates: write (QPS, объём данных), read (QPS, объём) 5. Storage estimates 6. Memory estimates: какие данные кладём в кэш; сколько RAM и сколько машин нужно; сколько на disk/ssd ### Шаг 3. Design goals [5 мин] 1. Требования по латентности и throughput 2. Consistency vs Availability, с расшифровкой автора: - weak/strong/eventual → это про **консистентность** - failover/replication → это про **доступность** ### Шаг 4. High level design [5–10 мин] 1. API для read/write-сценариев ключевых компонент 2. Схема БД 3. Базовый алгоритм 4. Крупноблочная схема для read- и write-сценария ### Шаг 5. Deep dive [15–20 мин] 1. Масштабирование алгоритма 2. Масштабирование каждой компоненты: availability/consistency/scale-история по каждой; паттерны консистентности и доступности 3. Меню компонент — «подумать, как каждая впишется и чем поможет»: - **DNS** - **CDN** — push vs pull - **Load balancers** — active-passive, active-active, L4, L7 - **Reverse proxy** - **Application layer** — микросервисы, service discovery - **БД** — RDBMS vs NoSQL: - RDBMS: master-slave, master-master, federation, sharding, денормализация, SQL tuning - NoSQL (key-value, wide-column, graph, document); быстрые lookup'ы: - RAM [ограниченный размер] → Redis, Memcached - AP [неограниченный размер] → Cassandra, Riak, Voldemort - CP [неограниченный размер] → HBase, MongoDB, Couchbase, DynamoDB - **Кэши** — уровни (клиент, CDN, веб-сервер, БД, приложение; на уровне запроса / объекта); паттерны: cache-aside, write-through, write-behind, refresh-ahead - **Асинхронность** — message queues, task queues, back pressure - **Связь** — TCP, UDP, REST, RPC ### Шаг 6. Justify [5 мин] 1. Throughput каждого слоя 2. Латентность, добавляемая между слоями 3. Суммарное обоснование общей латентности ## 2. Правки и дополнения из комментариев Комментарии к посту содержат две содержательные правки и одно дополнение — учтены в карточке §7: - **Поправка (216 апвоутов):** cache-aside / write-through / write-behind / refresh-ahead — это **паттерны кэширования, а не eviction-политики** (в оригинале ошибочно названы eviction). Вытеснение — LRU, LFU, FIFO. В конспекте выше и в карточке — исправленная версия. - **Пропущена security** (garbagecan): автор шаблона не включает безопасность; в зависимости от индустрии стоит покрыть (authn/z, лимиты, абьюз). У нас это уже есть — KB §13.7 и этап 6. - **Пропущены telemetry и logging** (struggling_coder): для быстрого реагирования on-call. У нас закрыто этапом 6 и KB §10. Вывод: оба пробела — ровно те места, где яндекс-формат шире шаблона (этап 6 «Эксплуатация» у LeetCode отсутствует целиком). ## 3. Маппинг на 6 этапов Яндекса Ключевое расхождение: шаблон выносит **все оценки вперёд** (шаг 2 до дизайна), Яндекс — разводит грубые числа на этап 1 (ими проектируем) и полный back-of-envelope на этап 5 (ими обосновываем). Второе расхождение: у шаблона нет эксплуатации вовсе. Адаптация: позвоночник — этапы Яндекса (`../methodology.md` §1), начинка — чек-листы шагов шаблона. | Шаг шаблона | Этап Яндекса | Как переносим | |---|---|---| | 1. Feature expectations | 1. Требования | Прямое совпадение: use cases + «что не строим» (= наш минус-объём) + кто/сколько/паттерны | | 2. Estimations | 1 (грубо) + 5 (подробно) | DAU→RPS и R/W ratio — на этапе 1; storage/RAM/bandwidth/ноды с формулами — этап 5 | | 3. Design goals | 1. Требования | CAP-декларация одной фразой в нефункциональных: «консистентность weak/strong/eventual — где; доступность — failover/репликация» | | 4. High level design | 2. Потоки и API + 3. Крупноблочная схема | API → этап 2; схема → этап 3; схему БД шаблон кладёт сюда — у Яндекса модель данных на этапе 4, оставляем яндекс-порядок | | 5. Deep dive | 4. Детали + БД | Меню компонент — не «обход по списку», а чек-лист для мысленного прогона при детализации горячего пути; A/C/S-история каждой компоненты | | 6. Justify | 5. Ресурсы + финал этапа 6 | Послойная пропускная + латентность между слоями = бюджет латентности против SLO; плюс возврат к листу требований | | — (отсутствует) | 6. Эксплуатация | Явное яндекс-добавление: ДЦ, отказы по узлам, мониторинг, релизы, поведение при перегрузке (KB §9–10) | ## 4. Что уникально против наших материалов - **Мнемоника выбора KV-хранилища** «RAM / AP / CP × ограниченный-неограниченный размер» — компактнее нашей таблицы классов (KB §3), совпадает с ней по сути: сначала свойство (RAM-bounded? AP или CP?), потом примеры-кандидаты. - **Послойный justify** (шаг 6) — «throughput каждого слоя + латентность между слоями + суммарная латентность» — латентность как бухгалтерия бюджета по слоям, а не одна цифра в конце; усиливает наш этап 5 (`../methodology.md` §2). - **Меню компонент** шага 5 — готовый список «что прогнать мысленно» (DNS, CDN push/pull, LB L4/L7 active-active, reverse proxy, service discovery, БД, кэш, очереди, транспорт) — у Поломодова и Яндекса такого сжатого перечня нет. - Чего в шаблоне нет и что берём из своих материалов: числа (KB §1–2), речевые паттерны и управление интервью (`../methodology.md` §3), эксплуатация (KB §9–10), глубина паттернов (KB §3–8, `sdp-guide.md`). ## Связанные документы - `../methodology.md` §7 — адаптированная карточка-памятка (итог этого материала) - `../methodology.md` §1 — 6 этапов яндекс-формата (позвоночник карточки) - `../knowledge-base.md` §3 (классы хранилищ), §4 (кэш), §9–10 (отказы, эксплуатация), §13.7 (security) - `lsd-polomodov-guide.md` — альтернативный фреймворк 7 этапов (45.20) - `learn-system-design-index.md` — индекс подборки (материал 18, P1)