title: Системный дизайн — база знаний (числа, back-of-envelope, хранилища, паттерны, карта DDIA) source: подготовлено 2026-09-17, основание — TASK-45.1; источники — System Design Primer (Appendix + гайд), статья Яндекса habr 564132, DDIA Клеппмана, interactive latency (colin-scott, TASK-45.25), производственный опыт

База знаний по системному дизайну

Плотный справочник для архитектурной секции. Задача документа — чтобы на секции числа, названия паттернов и трейдоффы звучали из головы, без пауз. Формат: таблицы + короткие правила проговаривания. Как пользоваться: §1–2 выучить до автоматизма (это скелет back-of-envelope), §3–4 — критерии выбора, §5–11 — словарь паттернов с формулировками для доски, §12 — карта DDIA, §13 — карта инфографики «System Design Blueprint» с мини-блоками, которых не было в §1–12.

1. Числа

1.1 Степени двойки

Размеры типовых сущностей (нужно для оценки storage):

1.2 Latency numbers every programmer should know

Производные метрики (та же таблица «на поток»):

Мнемоники: - Лестница ×1000: нс → мкс → мс → с. RAM — нс, SSD — мкс, HDD и сеть до другого ДЦ — мс, океан — сотни мс. - Каждый следующий уровень быстрее предыдущего в ~10–1000 раз; RAM быстрее SSD в ~100–1000 раз, SSD быстрее HDD-seek в ~100 раз. - «Память — это бесплатно, диск — это дорого, сеть через океан — это вечность»: отсюда все паттерны (кэш, батчинг, locality). - Избегать: random reads на HDD (10 мс seek), синхронных вызовов через океан в горячем пути, «одна лишняя цифра в латентности = другой дизайн». - Порог человеческого восприятия — ~100 мс: лаг меньше ~100 мс человек не замечает (источник 4, habr 516604). Отсюда SLO 150 мс у эталона Яндекса — «на грани комфорта», а round-trip через океан (~150 мс) сам съедает весь бюджет ответа.

Происхождение чисел: тренды железа (материал 21, colin-scott — интерактивная таблица «числа по годам»):

• CPU-числа — это такты: L1 = 3, branch mispredict = 10, L2 = 13, mutex = 50, сжатие 1 КиБ = 6 000 тактов; при 3 ГГц (0.33 нс/такт) → 1 / 3 / 4 / 17 нс / 2 мкс. На секции называть порядок, не десятые доли (CPU-числа плавают в разы от машины к машине, порядок — стабилен).
• Стена частот — 2005 год: герцы удваивались каждые 2 года до ~2005, дальше замерли на ~3 ГГц; расти продолжили ядра, не герцы. Однопоточная производительность исчерпана — горизонтальное масштабирование и конкурентность не выбор, а следствие.
• Полы латентности не двигаются 20+ лет: RAM 100 нс (шина даже деградирует с 2000), RT в ДЦ 0.5 мс, океан 150 мс — скорость света. Полосы при этом удваиваются: NIC ×2/2 года, DRAM и SSD ×2/3 года, HDD ×2/5 лет, HDD-seek — всего /2 за 10 лет (самый медленный тренд).
• Фраза для доски: «полоса дешевеет, латентность — нет» → батчить, пайплайнить, параллелить, меньше round trip'ов. Одним предложением объясняет пайплайны в протоколах, батчи в Kafka, мультиплексирование HTTP/2.
• Цветовая лестница ×100 (визуальная мнемоника источника): такты/нс → RAM/100 нс → сеть и SSD в ДЦ/10 мкс → диски и океан/мс — перепутать классы сложно: мьютекс не бывает «зелёным», RT в ДЦ — «синим».
• Ориентир свежести: обновление таблицы 2018 (Jeff Dean) — сжатие 1 КиБ 10 → 2 мкс, SSD random read 150 → 16 мкс; на секции безопаснее консервативные значения канона. Конспект и пересчёт тренд-модели → materials/lsd-interactive-latency.md.

1.3 Календарные константы

Availability в минутах простоя: 99 % = 3.65 дня/год; 99.9 % («три девятки») = 8.7 ч/год; 99.99 % = 52 мин/год; 99.999 % = 5 мин/год (доп. Alex Xu, гл. 2: простой = (100 − SLA)% × год).

2. Back-of-envelope estimation

2.1 Метод (порядок вопросов себе)

1. Масштаб пользователей: DAU / MAU, пик одновременных.
2. RPS: QPS_avg = DAU × запросов/сутки / 86 400; QPS_peak ≈ 2–3 × QPS_avg (утро/вечер, релизы). Reads обычно ≥ writes в 10–100 раз; запись чаще всего и есть узкое место по консистентности.
3. Storage: записей/с × размер × секунд/год × retention × фактор репликации + индексы (×2 от сырых данных — хорошая прикидка).
4. Bandwidth: чтение = read QPS × размер объекта, запись = write QPS × размер. Сравнить с 1/10 Gbps NIC и решить: нужен ли CDN / сжатие.
5. Память кэша: правило 80/20 — кэшируем горячие 20 %; память = 0.2 × DAU × запросов/сутки × размер объекта.
6. Серверы: типовое приложение-сервис держит ~1–10 тыс. RPS на ноду (зависит от работы: CPU-bound vs IO-bound); БД — лучше не считать «одна нода потянет», а сразу делить роли.

Правило разговора: назвать допущение → формулу → число → вывод («это терабайты, влезает в одну ноду, значит узкое место не storage, а RPS на чтение → кэш/KV-зеркало»).

2.2 Пример 1: storage (URL shortener)

Дано: 100 млн новых ссылок/месяц, retention 10 лет, запись ~500 байт.

• Записи: 100M × 12 мес × 10 лет = 12 млрд записей.
• Сырые данные: 12G × 500 Б = 6 ТБ; с индексами и оверхедом ×2 → ~12 ТБ.
• Вывод: 12 ТБ — это одна-две ноды с дисками; storage не узкое место. Значит дизайн крутится вокруг чтения (см. classic-designs.md: 500k RPS → KV-зеркало + кэш).

2.3 Пример 2: RPS (лента новостей)

Дано: 100 млн DAU, пользователь открывает ленту 10 раз/сутки, публикует 2 поста/сутки, в среднем 300 подписчиков.

• Чтение: 100M × 10 / 86 400 ≈ 11.5k QPS avg, пик ×3 → ~35k QPS.
• Запись постов: 100M × 2 / 86 400 ≈ 2.3k QPS.
• Fan-out: каждый пост → 300 вставок в ленты подписчиков → 2.3k × 300 ≈ 700k вставок/с в кэш лент. Вот здесь узкое место: не пост, а доставка. Отсюда выбор fan-out on write vs read и микс для селебрити (см. classic-designs.md §2).

2.4 Пример 3: bandwidth (видео-хостинг)

Дано: 10 тыс. загрузок/сутки × ~1 ГБ исходник; 100 тыс. просмотров/сутки, средний просмотр 5 мин при битрейте 3 Mbps ≈ 110 МиБ.

• Storage-рост: 10k × 1 ГБ = 10 ТБ/сутки исходников + транскоды ×3–5 версий → 30–50 ТБ/сутки. Через год — десятки ПБ: только объектное хранилище (S3-класс), никакой NAS.
• Egress: 100k × 110 МиБ ≈ 10 ТБ/сутки → средний поток 10 ТБ / 86 400 с ≈ 120 МБ/с ≈ 1 Gbps, пик ×3–5 → 3–5 Gbps. Вывод: отдавать клиентам напрямую из кластера нельзя (дорого и медленно глобально) → CDN с offload 90 %+.
• Транскодинг: 10k видео/сутки, минуты CPU на минуту видео → асинхронный пайплайн через очередь (обработка может отставать от загрузки на минуты — это приемлемо и проговаривается).

2.5 Гигиена оценок и пример Twitter (Alex Xu, гл. 2)

Правила из книги — как подавать прикидку на секции:

• Округлять до круглых чисел: не 11.64 МБ, а «примерно 10 МБ» — интервью про порядок, а не про точность.
• Записывать допущения (письменно/на доске): «предположим 100 млн DAU, 2 твита/день» — интервьюер сможет поправить, а не оспорить результат.
• Подписывать единицы: KB — килобайт, Kb — килобит (×8 разницы); латентность в мс, bandwidth в МБ/с.
• Пример книги (Twitter): 100M DAU × 2 твита ≈ 2300–3500 QPS запись; медиа ~30 ТБ/день; 5 лет ≈ 55 ПБ — порядок величин важнее цифр.

3. Классы хранилищ и критерии выбора

Как отвечать на секции (по одному предложению на выбор): «Данные реляционные и за деньги → PostgreSQL; hot path по ключу с RPS, которые не тянет SQL → KV-зеркало/Redis; поиск → инвертированный индекс; аналитика → колоночная БД; медиа → S3 + CDN; событийная интеграция → Kafka. Источник правды один (RDBMS), остальные — производные проекции с известным лагом».

3.1 Движки хранения: LSM vs B-tree (DDIA 2-е изд., гл. 4)

Два семейства OLTP-движков — классический вопрос этапа 4 «а как внутри вашей БД»:

• LSM-tree (RocksDB, Cassandra, HBase, LevelDB): запись → memtable (отсортированная структура в памяти) → flush в SSTable (иммутабельные отсортированные файлы на диске, компрессия, sparse index); фоновая компактация сливает сегменты как mergesort; удаление — tombstone; Bloom filter отсекает чтение отсутствующих ключей; компактация size-tiered (сначала мелкие равного размера) vs leveled (уровни по размеру) — компромисс write/пространство.
• B-tree (PostgreSQL, MySQL, почти все RDBMS): страницы фиксированного размера, обновление на месте, глубина O(log n) — на практике 3–4 уровня (≈250 TB при branching factor ~500); page split при заполнении; надёжность через WAL (журнал до модификации страниц); copy-on-write варианты (LMDB) дают снапшоты.
• LSM vs B-tree: LSM — выше write throughput (только последовательные записи, ниже write amplification, лучше компрессия), плата — чтение старых ключей дороже (несколько SSTable), range слабее, компактация конкурирует за IO → латентность-спайки; B-tree — предсказуемое точечное чтение и range, плата — write amplification (WAL + запись страницы целиком). SSD: sequential > random даже на flash (erase block ~512 KiB).

4. Кэш

Стратегии: - Cache-aside (базовая): приложение читает кэш, при промахе — БД и запись в кэш; при записи — БД, кэш инвалидируется. Просто, консистентность через TTL. - Read-through / write-through: кэш-слой сам ходит в БД; запись идёт сквозь кэш. Строже, но дороже на запись. - Write-behind (write-back): запись в кэш, в БД — асинхронно батчами. Быстро, но риск потери при падении — проговаривать явно. - Refresh-ahead: предиктивное обновление горячего до истечения TTL (профилактика stampede).

Инвалидация: TTL (универсальная страховка), инвалидация по записи (delete, не update), версионированные ключи (key:v2), событийная инвалидация через шину (Kafka → удалить/прогреть). Классическая гонка «читатель успел положить старое после записи» → лечится коротким TTL; радикально — delayed double delete.

Cache stampede (thundering herd): истечение тысячи горячих ключей разом роняет БД. Защиты: (1) single-flight / distributed lock — один запрос пересчитывает, остальные ждут; (2) probabilistic early expiration (XFetch) — обновлять заранее с вероятностью, растущей от близости TTL; (3) разогрев и разнесённые TTL (jitter).

Прочее, что надо проговаривать: hit ratio цель 90 %+ для hot path; LRU как дефолт, LFU для неравномерных; hot key (селебрити) → локальный L1 + реплики ключа; метрики кэша обязательны (hit ratio, evictions, latency).

5. Репликация

• Leader–follower (базовая): запись на лидера, реплики тянут WAL/binlog. Sync — не теряем данные, платим латентностью; async — быстро, лаг и потери при failover; semi-sync — компромисс (ждём ACK одной реплики).
• Replication lag: read-your-writes ломается. Средства: читать свои записи с лидера (sticky), монотонное чтение с одной реплики, версионные токены (LSN), наблюдение за lag как SLO.
• Multi-leader: несколько пишущих узлов (мульти-ДЦ, оффлайн-клиенты). Плата — конфликты writes; решение: LWW (теряет данные), CRDT, ручное разрешение. На секции: «избегаю без необходимости».
• Leaderless (Dynamo-стиль): пишем в W реплик, читаем из R, при W + R > N читаем свежее; hinted handoff, read repair, anti-entropy (Merkle-деревья). Tunable consistency. Членство/детект отказов — gossip-протокол (без центрального детектора = без SPOF); при недоступности «своих» узлов — sloppy quorum: пишем на ближайшие доступные с hint, отдаём владельцу позже (Alex Xu, гл. 6).
• Failover: детект (heartbeat + кворум), выбор нового лидера, fencing старого (split brain = два лидера пишут — катастрофа), автоматический vs ручной (проговаривать: автоматика быстрее, но ложные failover дороже простоя).
• Что реплицируем (DDIA 2-е изд., гл. 6): statement-based (нестабильно: now()/rand()), WAL (привязан к версии движка), logical/row-based лог — переносимый компромисс, фундамент CDC; сессионные гарантии формулируются по позиции в логе (read-your-writes = «читай с реплики, дотянувшей позицию моей записи»; monotonic reads = приклеивание к реплике; consistent prefix reads = порядок причинных записей). Кворумы W+R>N дают свежесть, но не linearizability — см. §7.

6. Шардирование

Сначала — а надо ли? Лестница «до шардирования»: индексы → вертикаль (железо) → реплики на чтение → кэш → денормализация/проекции → и только потом шарды. Шардирование — последняя ступень, потому что оно ломает транзакции, JOIN и операции.

Стратегии: - Range: по диапазону ключа (даты, ID-отрезки). Плюс — range-запросы, минус — hot spot на «свежем» диапазоне. - Hash: равномерно, но нет range-запросов; перешардирование болезненное. - Consistent hashing: кольцо + виртуальные ноды (100–200 на ноду) → при добавлении/уходе узла переезжает ~1/N ключей, а не почти всё. Стандартный ответ на «как перекладывать шарды без даунтайма». - Directory: lookup-сервис хранит карту; гибко (неровные данные), но сама карта — точка отказа/кэширования.

Hot partition: селебрити/перегретый ключ перекашивает шард. Средства: salting (ключ + суффикс с последующей агрегацией), выделение горячего в отдельный шард/сервис, локальный кэш на ноде.

Шард-ключ — главное решение: выбирается по access pattern, менять после — переливка всех данных. Кросс-шардные транзакции и JOIN → избегать (денормализация, 2PC — осторожно, см. §7). Ребалансировка: удвоение числа шардов заранее, миграция в фоне с dual-read.

Поверх шардов (DDIA 2-е изд., гл. 7): - Вторичные индексы: local (каждый шард ищет сам → scatter-gather по всем шардам) vs global (сам распределён по ключу индекса — быстрее поиск, но отстаёт от записи и hot-spot-уязвим). - Сколько шардов: фиксированное число маленьких шардов заранее — миграции дешевле, но больше метаданных; динамическое расщепление — автоматика, но движущиеся границы. Не mod N (двигается почти всё). - Request routing: «где мои данные?» — слой маршрутизации + метаданные в координационном сервисе + кэш на клиенте; изменение членства — gossip/notifications. - Мультиарендность: tenant_id в ключе шарда; шумные соседи (noisy neighbors) изолируются выделенными шардами.

7. Консистентность и распределённые транзакции

• CAP: при сетевом разделении (P — не опция, оно случается) выбираем C или A. Формулировка для доски: «в одном ДЦ почти всегда C; между ДЦ — вынужденно AP с eventual».
• PACELC: даже без разделения (Else) платим Latency за Consistency или наоборот. Честнее CAP в обычной жизни: строгая консистентность = дополнительный round-trip.
• Модели: linearizability (выглядит как одна копия; дорого) → sequential → causal → eventual (дёшево, но аномалии: read-your-writes, monotonic reads нужно обеспечивать отдельно).
• Quorum: W + R > N гарантирует пересечение; настройка W=N/R=1 (строгая запись), W=1/R=N (строгое чтение), промежуточные — по чтению/записи. Конфликты параллельных версий отслеживаем векторными часами (счётчики по узлам в каждой записи): определяют причинность; параллельные ветки → отдаём клиенту обе версии, слияние вручную (Alex Xu, гл. 6, Dynamo).
• 2PC (prepare/commit): строгая атомарность, но координатор — точка блокировки и отказа; на секции говорить: «в высоконагруженных системах избегаю, применяю саги».
• Saga: последовательность локальных транзакций + компенсирующие действия при откате (order → reserve → charge → ship; откат = cancel/refund). Оркестрация (координатор) vs хореография (события через шину).
• Transactional outbox: запись в БД и публикация события атомарно: событие пишется в outbox-таблицу в той же транзакции, отдельный воркер/CDC (Debezium) публикует в Kafka. Решает «БД записала, событие потерялось».
• Идемпотентность: точно-once между системами не существует — есть at-least-once + дедупликация (idempotency key, уникальные constraint, таблица обработанных).

Уровни изоляции и гонки (DDIA 2-е изд., гл. 8): read committed (нет dirty read/write: MVCC — читатели видят закоммиченные версии, row-lock на запись) → snapshot isolation (транзакция читает согласованный снапшот на старте) → serializable (2PL или SSI: MVCC + отслеживание опасных rw-антизависимостей → abort вместо блокировок). Гонки: lost update (read-modify-write; лечится SELECT FOR UPDATE / CAS / автоматическим детектом в MVCC), write skew (две транзакции читают пересечение, пишут разные строки — инвариант сломан; лечится serializable/constraint/материализацией конфликта), phantom (предикатные чтения → predicate locks).

Linearizability vs serializability (DDIA 2-е изд., гл. 10, вопрос-ловушка): linearizability — гарантия свежести одной операции («после завершения записи все читают новое», система выглядит как одна копия); serializability — гарантия изоляции транзакций (порядок любой, если эквивалентен последовательному). Вместе = strict serializability (Spanner, FoundationDB). Нужна для: lock/leader election, uniqueness-ограничений, cross-channel timing. Дают: single-leader (пока лидер настоящий) и консенсус; кворумы W+R>N НЕ дают (гонки concurrent read repair; LWW по wall-clock — тем более теряет данные).

Часы и порядок (DDIA 2-е изд., гл. 9–10): time-of-day (NTP, прыжки, drift до 200 ppm) против monotonic (только интервалы). Lamport clock (counter+nodeID) и hybrid logical clock (HLC) дают total order, согласованный с причинностью — но не linearizability; параллельность детектируют только vector clocks (дороже по размеру). ID: автоинкремент = linearizable fetch-and-add; Snowflake/UUIDv4/ULID теряют порядок.

Консенсус (DDIA 2-е изд., гл. 10): эквивалентные формулировки — single-value consensus, linearizable CAS, shared log (total order broadcast), atomic commit, fetch-and-add; свойства agreement/integrity/validity (safety — держится всегда) + termination (liveness — требует большинства живых). Механика: epoch/term, уникальный лидер эпохи, два голосования (выборы + коммит) с пересекающимися кворумами. Практика — координационные сервисы (ZooKeeper/etcd/Consul): locks/leases + fencing tokens (zxid/cversion в ZooKeeper, revision в etcd, epoch в Kafka; term/ballot в Raft/Paxos) + failure detection (сессии, ephemeral nodes) + change notifications; service discovery — кэшировать (observers).

Распределённые транзакции на практике (DDIA 2-е изд., гл. 8): 2PC/XA — in-doubt транзакции держат локи при падении координатора, «heuristic decisions» ломают атомарность; NewSQL (CockroachDB, Spanner, TiDB, FoundationDB, транзакции Kafka) — реплицированный координатор на консенсусе, без XA-болей. Exactly-once без распределённых транзакций: таблица обработанных message-ID в локальной транзакции = идемпотентный консьюмер (так делает Kafka Streams).

8. Очереди и потоковая обработка

Зачем: развязка сервисов, буферизация пиков (load leveling), ретраи, broadcast, порядок и реплей. Плата: лаг, дубли, сложность отладки.

Kafka — словарь: topic → партиции (порядок и параллелизм внутри партиции; ключ маршрутизирует), consumer group (каждая партиция — одному консьюмеру группы), offsets (позиция, коммитится; реплей с любого offset), retention по времени/размеру (лог можно перечитать), ISR для надёжности, acks=all для данных, которые нельзя терять.

Delivery semantics: - At-most-once — может потерять, не дублирует (fire-and-forget). - At-least-once — дефолт надёжных систем; дубли неизбежны → потребитель обязан быть идемпотентным. - Effectively-once — at-least-once + дедуп (Kafka transactions / idempotent producer / ключи дедупа на стороне потребителя).

Паттерны: DLQ для ядовитых сообщений, backpressure (не тащим быстрее, чем можем обработать), competing consumers для масштаба, приоритетные очереди (отдельные топики), dead man's switch на затишье.

Группы потребителей (DDIA 2-е изд., гл. 12): одна consumer group — load balancing (партиция — одному консьюмеру группы), разные группы — fan-out (каждая получает всё); acknowledgments + redelivery. Обычные брокеры (AMQP/RabbitMQ) — delete-after-delivery; log-based (Kafka) — append-only партиции, consumer offsets, retention и реплей.

CDC и компоновка (DDIA 2-е изд., гл. 12): CDC — репликационный лог БД → стрим (Debezium/Kafka Connect): БД не знает об этом, исторические данные — через initial snapshot + offset; log compaction — по ключу хранится только последнее значение (навсегда), а не окно по времени. CDC (факты изменений) ≠ event sourcing (намерения домена). Окна: tumbling/sliding/session; event time vs processing time (часы клиентов плывут — watermarks для закрытия окна).

9. Отказоустойчивость

Изоляция и деградация: - Timeout на каждый внешний вызов — без него один зависший dependency съедает потоки. - Retries: экспоненциальный backoff + jitter; только идемпотентные операции; ограничение числа попыток. - Circuit breaker: closed → (ошибки > порога) → open (фейлим сразу, дёшево) → half-open (пробный запрос). Защищает от каскадного падения и даёт зависимости время восстановиться. - Bulkhead: отдельные пулы соединений/потоков на dependency; падение одного не топит остальные. - Rate limiting: token bucket / leaky bucket / sliding window; на клиенте (борьба с абузой) и на сервере (self-protection); 429 + Retry-After; в распределёнке — Redis + Lua или лимитер на шлюзе. - Load shedding: при перегрузке отказываем «дешёвым» запросам, спасаем критичные; graceful degradation — отдаём кэш/неполные данные вместо ошибки.

Резервирование: N+1 на каждом ярусе; active–active (мульти-ДЦ, дороже, выше утилизация) vs active–passive (проще, тёплый простой). Health checks (liveness/readiness), автоматический failover с кворумом.

Арифметика надёжности: доступность цепочки = произведение; параллель = 1 − ∏(1−ai). «Три девятки» = 8.7 ч/год — уже требует резервирования всего пути.

Слабые места распределённой среды (DDIA 2-е изд., гл. 9): - Partial failure — норма: «работает или нет» больше нет; сеть асинхронна — потерянный запрос, очередь, упавшая нода, GC-пауза, потерянный ответ не отличить; таймаут — догадка; «нет ответа» ≠ «не выполнилось» → ретраи только для идемпотентного. - Часы: time-of-day (NTP: прыжки, drift) для wall-clock опасен (LWW теряет данные), интервалы — только monotonic; между машинами время несравнимо. - Process pauses / зомби-лидер: GC, VM suspend, swap — нода «засыпает» на секунды, не замечая истёкшего lease; защита — fencing token на каждом grant, хранилище отвергает старые (см. §7). - Кворум объявляет мёртвым — нода обязана подчиниться: узел знает только полученные сообщения; majority-кворум — единственный с гарантированным пересечением. - System models: реалистичная — partially synchronous + crash-recovery; safety (не нарушается никогда) vs liveness («eventually», при живом большинстве); Byzantine (враньё узлов) — вне охвата датацентров, от слабого вранья — checksums/валидация входа; gray failure (limping node) — хуже чистого отказа.

10. Эксплуатация (говорим на секции всегда)

• Golden signals (Google SRE): latency (отдельно ошибки и успехи!), traffic, errors, saturation. Метрики каждого яруса: QPS, p50/p95/p99, error rate, очередь/лаг, утилизация (CPU, память, соединения).
• SLI/SLO/SLA + error budget: SLO 99.9 % даёт бюджет 43 мин/мес; бюджет кончился — фризим фичи, чиним надёжность. На секции это маркер production-зрелости.
• Релизы: rolling, canary (1 % → 10 % → 50 % → 100 % с авто-откатом по метрикам), blue-green (мгновенный откат переключением), feature flags (расходим деплой и релиз фичи).
• Миграции без даунтайма — expand/contract: 1) расширяем схему (новая колонка/таблица, nullable, backfill в фоне), 2) двойная запись/чтение-сравнение, 3) переключаем чтение, 4) контракт: убираем старое. Каждый шаг — рабочий релиз. Antipattern: большие миграции ALTER на живых больших таблицах и dual writes без сверки.
• Наблюдаемость: metrics (Prometheus) + logs (структурированные) + traces (OpenTelemetry, сквозной trace id). Алерты на симптомы (SLO burn), а не на причины.
• Ёмкость: план на пики (реклама, праздники), headroom ≥ 2×, регулярный load-тест.
• Хвостовая латентность и metastable failure (DDIA 2-е изд., гл. 2): считать p50/p95/p99, среднее врёт; tail amplification — один медленный вызов в fan-out-цепочке тянется в общую p99 (N бэкендов → почти каждая страница ловит хвост). Metastable failure: перегруз → таймауты → retry storm → система «застревает» в перегрузе даже после спада нагрузки; лечится exponential backoff + jitter, circuit breaker, load shedding, backpressure. Словарь: response time ≠ service time ≠ latency (очередь — главный источник задержки).

11. Мини-шпаргалка «что назвать на секции»

12. Карта DDIA (Клеппман, «Высоконагруженные приложения»)

⚠️ Карта ниже — по 1-му изданию (= русский перевод). Вышло 2-е издание (Kleppmann & Riccomini, 2025, 673 стр.): гл. 1 переписана, гл. 2 новая (НФТ + кейс лент), старые гл. 5–9 → 6–10, + логические часы и ID-генераторы, + durable execution/workflow engines в гл. 5. Соответствие глав и приоритеты 2-го изд. (6–10 ядро, 1–5 вторично, 11–13 опционально, 14 — этика) — materials/ddia-map.md §0; полный текст 2-го издания с выжимками — materials/ddia-2ed/ch-*.md (TASK-45.39).

Приоритеты: ЯДРО — читать обязательно, именно отсюда вопросы секции; вторично — к интервью после ядра; опционально — после секций / для общего развития.

Часть I. Основы данных (главы 1–4)

Часть II. Распределённые данные (главы 5–9) — сердце книги и секции

Часть III. Производные данные (главы 10–12)

Порядок чтения к слотам (18.09 / 21.09 / 22.09)

• До слота 18.09: гл. 1, 3, 5, 6 (+ детальный конспект URL shortener из статьи Яндекса). Это скелет: числа, хранение, репликация, партиции.
• Между 18.09 и 21.09: гл. 7, 8, 9 — транзакции, отказы, консистентность/консенсус. Самое плотное ядро.
• Перед 22.09: гл. 11 + повтор конспектов по ч. II; гл. 2, 4 — по остатку времени.
• Гл. 10 и 12 — после секций, для собеседований уровнем выше.
• После каждой главы — 5-минутный пересказ схемы вслух у доски (протокол тренировки — methodology.md).

Детальная проработка карты чтения и привязка к слотам — materials/ddia-map.md (TASK-45.10).

13. Инфографика System Design Blueprint (learn-system-design) — карта и дополнения

Источник: system-design-guide.jpeg из подборки learn-system-design («System Design Blueprint: The Ultimate Guide», TASK-45.12): весь путь запроса на одном листе — DNS → балансировщик → API-шлюз → бэкенды → кэш/очереди → БД → хранение медиа, плюс сквозные темы. Большая часть уже покрыта §3–§11; ниже — карта «блок → где в KB» и мини-блоки, которых не хватало. Полная послойная расшифровка — ✅ TASK-45.24 (materials/lsd-ultimate-guide-image.md), индекс всей подборки — materials/learn-system-design-index.md.

Послойная расшифровка листа и маппинг «блок → где в KB» — materials/lsd-ultimate-guide-image.md (TASK-45.24); ниже §13.1–13.7 — мини-блоки с формулировками, §13.8 — дополнения по итогам полной расшифровки.

13.1 DNS — одной фразой на секции

Цепочка: клиент → рекурсивный resolver (ISP) → root NS → TLD NS (.com) → authoritative NS → IP; каждый уровень кэшируется с TTL. GeoDNS отдаёт IP ближайшего региона — с этого начинается «мульти-ДЦ». Формулировка: «клиент резолвит домен, GeoDNS ведёт в ближайший регион, дальше весь трафик — в LB». Не углубляться.

13.2 Алгоритмы балансировщика

Round Robin (stateless-дефолт) • Weighted RR (ноды разной мощности) • Least Connections (долгие соединения: websocket/streaming) • Hash/IP-sticky (сессии, кэш-локальность; вместе с consistent hashing — ответ про масштабирование пула LB) • Random (говорим, что не выбираем). Обязательная фраза: «перед LB — health checks, нездоровую ноду выбрасываем из ротации».

13.3 Real-time транспорт — выбор по направленности и совместимости

13.4 Распределённая генерация ID (URL shortener, лента, заказы)

• UUID v4: без координации, но 128 бит и нет порядка → плохие индексы и шардирование по времени.
• Auto-increment × N нод (чёт/нечет или шаг N): просто, но плохо масштабируется и предсказуемо.
• Snowflake (64 бита: 41 время + 10 нод + 12 секвенция): хронология «бесплатно», дружелюбно индексам и шардированию; семейство — Baidu UID, Sonyflake. Дефолтный ответ для ID сущностей в масштабе.
• Централизованный генератор (ticket service): просто, но точка отказа; лечится кэшированием диапазонов.

13.5 Распределённые локи и координация

Redis (Redlock) — быстро, компромисс по надёжности; ZooKeeper/etcd/Chubby — кворумные, надёжнее и дороже. Применение: leader election, single-flight пересчёт кэша (stampede, §4), дедуп критичных операций. Оптимистичная блокировка (версия/CAS) — дефолт; пессимистичная — короткие критические секции. При локах проговаривать fencing token и «лок ≠ транзакция» (§5, §7).

13.6 Гео-шардирование и пространственные данные

Гео-шарды (по регионам): локальность данных, latency, GDPR-границы; цена — кросс-региональная консистентность (§7). Запросы «ближайшие N объектов» — geohash/QuadTree + R-деревья; на задачах Uber/карт-класса это ключевой блок выбора БД.

13.7 Платежи и security — сквозные темы секции

Платежи: charge-сервис с idempotency key (повтор запроса ≠ двойное списание), статус-машина платежа, внешний banking-провайдер = медленная зависимость → таймаут/ретрай/очередь + сверка (reconciliation). Ошибки домена (карта просрочена, недостаточно средств, провайдер недоступен) — обрабатываемые ветки, не 500.

Security-чеклист (назвать всегда): OAuth 2.0/JWT, RBAC, TLS in-transit + шифрование at-rest, audit trail, input validation, signed URLs на приватные объекты (медиа), rate limiting (§9).

13.8 Дополнения по полной расшифровке листа (TASK-45.24)

Мини-факты, которых не было в §1–13.7; формулировки — как на листе, добавлена расшифровка «зачем»:

• API-шлюз, ответная сторона (просим не забыть): gzip/deflate, Request ID (трассировка), pagination, expiry-заголовки (кэш-контроль), mime, cookie, коды/тексты ошибок. Запросная сторона: валидация, auth (OAuth 2.0), rate limit, whitelist/blacklist, flow control, TLS termination, дедуп по idempotency key, metering/диспетчеризация.
• CDN — push hot / pull rare / hybrid: горячее проталкиваем на край заранее, редкое тянем по промаху, обычно гибрид; метрики края — cache miss outs, active/total resources.
• Генерация ID — offline generations: генератор выдаёт нодам диапазоны заранее — сервис не стоит на критическом пути записи (дополняет snowflake, §13.4).
• Конкурентность — serially batch: между «строго последовательно» и пессимистичными локами есть промежуточная ступень — последовательные батчи (дополняет §13.5).
• Upload медиа — metadata-таблица чанков: key | checksum | timestamp в in-memory key storage, целостность чанка проверяем по checksum при каждом чтении, таблицу синхронизируем централизованно; событие «новый чанк» фан-аутится в MQ → воркеры (транскодинг: compute time, failed count, encoded/compression ratio, storage consumed).
• Рекомендации — фильтры: content-based (по признакам контента) и collaborative (по поведению похожих пользователей) — назвать обе, если в системе есть лента/каталог.
• Метки наблюдаемости листа развешаны по компонентам (шлюз: 4XX/5XX/2XX, response time; очередь: count, consumption rate, in-transit waiting-for-ack, queue limit; БД: query time, throughput, active connections) — так и подавать на этапе 6: метрики привязаны к узлу, а не списком в конце.

14. Строительные блоки из Alex Xu Vol. 1 (TASK-45.38)

Источник: «System Design. Подготовка к сложному интервью» (рус. Vol. 1), полный текст глав — materials/alex-xu-vol1/ch-*.md, карта переноса — materials/alex-xu-vol1/_map.md. Здесь — паттерны, которых не было в §1–13: алгоритмы rate limiting (гл. 4), краулер (гл. 9), уведомления (гл. 10), автозаполнение (гл. 13), блочное хранилище (гл. 15). Snowflake — §13.4; транспорт (polling/WS) — §13.3; consistent hashing — §6; Dynamo-механики — §5/§7.

14.1 Алгоритмы rate limiting (гл. 4)

Распределённый лимитер: Redis + Lua (атомарный check-and-set, иначе race между воркерами); multi-DC → лимитер на edge (GeoDNS → ближайший узел), консистентность между узлами — eventual, учесть в бенчмарках. Эксплуатация: заголовки X-RateLimit-*, код 429, мониторинг доли заблокированных (высокая = абьюз или неверный лимит). Клиентские лимитеры (в приложении) — для экономии вызовов, серверные — источник правды.

14.2 Поисковый краулер (гл. 9)

Характеристики: масштабируемость, устойчивость, вежливость (не DDoS чужие серверы), расширяемость (плагины). Компоненты: seed URL → frontier (очередь на загрузку) → загрузчик HTML (+DNS-кэш — узкое место, 10–200 мс) → дедуп контента по хешам (29 % страниц — дубликаты; фильтр Блума для «видели URL?») → извлекатель ссылок → фильтр URL → хранилище URL.

Frontier — сердце: лицевые очереди (приоритет: PageRank, популярность, частота обновления) + тыльные очереди (вежливость: домен → таблица связывания → своя FIFO → выделенный рабочий поток с задержкой). BFS «в лоб» бьёт по одному домену и не учитывает ценность страниц. Ещё: robots.txt (кэшировать, уважать Disallow), гео-распределение, timeout на медленные серверы, состояние в хранилище (рестарт после сбоя), спайдертрапы (лимит длины URL, чёрные списки), server-side рендеринг JS-страниц.

14.3 Система уведомлений (гл. 10)

Каналы: APNs (iOS) / FCM (Android) / Twilio-Nexmo (SMS) / SendGrid-Mailchimp (email) — провайдеры сторонние, расширяемость обязательна (FCM недоступен в Китае → JPush). Паттерн: сервисы → серверы уведомлений (API, валидация, шаблоны) → очередь на каждый канал (отказ одного провайдера не роняет остальные) → воркеры → провайдеры. Надёжность: уведомление не теряется — журнал уведомлений в БД + retry из очереди; доставок может быть больше одной (at-least-once) → дедуп по ID события; rate limiting на получателя (иначе отписки); мониторинг длины очередей (растёт → добавляем воркеров); аналитика (открытия/клики/отписки), настройки opt-in. Это же — типовой ответ «как связать сервис с внешним миром».

14.4 Автозаполнение поиска / typeahead (гл. 13)

Требования: <100 мс, топ-5 по частоте, совпадение с начала строки. Прикидка: 10M DAU × 10 запросов × 20 символов ≈ 24k QPS (пик 48k) — запрос на каждый введённый символ. Ядро — trie (префиксное дерево) с частотами; наивный алгоритм O(p) + O(c) + O(c log c). Две оптимизации до O(1): (1) ограничить максимальную длину префикса; (2) топ-k популярных запросов прямо в каждом узле — память платим, латентность забираем. Данные строятся offline: логи → агрегаторы (частоты за период; для Google хватает недели, для Twitter — реальное время) → воркеры пересобирают trie → БД (документная/снимок или KV «префикс → список») → кэш trie в памяти → API. Шардирование — по диапазонам префиксов. Вариант вопроса «top-k самых частых запросов» — это он.

14.5 Блочное хранилище и синхронизация файлов (гл. 15, Google Drive/Dropbox)

Файл → блоки (~4 МБ) → сжатие по типу → шифрование → S3; метаданные (блоки + хеши, версии) — в реляционной БД (ACID): нужна строгая согласованность между кэшем и БД, инвалидация кэша при записи. Экономия трафика: дельта-синхронизация (передаём только изменённые блоки), дедупликация (одинаковый хеш = один блок), лимит версий, холодное хранилище (Glacier) для неактивного. Конфликты одновременного редактирования: побеждает первая обработанная версия, второму клиенту — обе версии на слияние/выбор. Уведомления об изменениях — long polling (одностороннее, редкие события — WebSocket избыточен); оффлайн-клиент — очередь автономной архивации. Таблицы: user, device (push_id), namespace, file, file_version (immutable), block.

15. Кодирование, эволюция схем и durable execution (DDIA 2-е изд., гл. 5)

Мини-блок под вопросы «как менять формат данных без даунтайма» и «какие alternatives сагам есть":

• Совместимость: backward (новый код читает старые данные) и forward (старый код — новые): обязательны при поэтапных релизах; потоки данных — через БД («сообщение будущему себе»), через сервисы (REST/RPC), через сообщения (брокер).
• Форматы: JSON/CSV — читаемые, объёмные, двусмысленность чисел; Protobuf/Avro — компактные, эволюция через схему (protobuf — теги полей, новые поля с новыми номерами; Avro — writer/reader schema, идеален для CDC), проверка совместимости до деплоя (schema registry).
• RPC не может спрятать сеть: частичные отказы, таймауты, семантика ретраев — те же проблемы, что у распределённых систем (§9).
• Durable execution / workflow engines (Temporal, Restate) — новое во 2-м изд.: оркестратор персистит состояние workflow в журнал, задачи идемпотентны и ретраятся движком; практическая альтернатива сагам и распределённым транзакциям для долгих бизнес-процессов (заказы, платежи, онбординг). На секции: «сага — дефолт; для долгих многошаговых процессов смотрю в сторону workflow-движков с durable execution».

Связанные документы

• ../interview-materials.md — общая карта материалов по вакансии
• materials/ — конспекты источников (статья Яндекса, System Design Primer, habr 516604, видео Gabbard, DDIA) + learn-system-design-index.md (индекс подборки, TASK-45.12) + lsd-ultimate-guide-image.md (расшифровка инфографики, TASK-45.24) + alex-xu-vol1/ (книга Алекса Сюя, полный текст глав + выжимки + карта переноса _map.md, TASK-45.38) + ddia-2ed/ (DDIA 2-е издание, полный текст глав + выжимки + карта переноса _map.md, TASK-45.39)
• methodology.md — фреймворк ответа, тайминг, план тренировки (TASK-45.2)
• classic-designs.md — эталонные разборы сервисов (TASK-45.3)
• ../algo-exam/complexity-cheat-sheet.md — методичка по алгоритмам (этап 1, закрыт)