Job 2026 md

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)