title: Конспект источника 3 — System Design Primer, основной гайд (donnemartin/system-design-primer) source: https://github.com/donnemartin/system-design-primer/blob/master/README.md author: Donne Martin (ex-AWS, автор sourcegraph/знаменитых repo); главный инженерный FAQ по системному дизайну на GitHub конспект: подготовлено 2026-09-17, TASK-45.7; тезисы и «disadvantage»-списки — дословная выжимка источника, формулировки «что проговаривать» и shared principles (§12.3) — наши дополнения по инструкции автора «identify shared principles»; Appendix (числа) не дублируется — см. sdp-appendix-numbers.md статус: словарь паттернов с трейдоффами — подкрепляет knowledge-base.md §3–11; каркас интервью (§1 конспекта) — западный вариант каркаса из methodology.md

Источник 3: System Design Primer — полный гайд

Самый известный опенсорс-гайд по системному дизайну (~100k+ звёзд): энциклопедия паттернов, где по каждому — краткое описание, применение и обязательный блок Disadvantages (цена решения — то, что интервьюеры любят слушать). Appendix (степени двойки, latency, список вопросов) разобран отдельно в sdp-appendix-numbers.md (TASK-45.6) — здесь не дублируется.

Как читать по отношению к нашей подготовке: Яндекс-статья (habr 564132) даёт формат секции, primer даёт словарь паттернов. Каркас ответа — из methodology.md §1; сюда ходим за «как называется паттерн, когда его применять и чем он плох». Прямое указание автора: «Everything is a trade-off» — каждая секция гайда построена как pros/cons; наш речевой паттерн «выбираю X, плачу Y» (methodology §3) — это ровно структура гайда.

1. Каркас интервью по SDP и его связь с яндексовским

SDP предлагает 4 шага (§ «How to approach a system design interview question»); по сути это сжатая версия яндексовских 5 этапов из methodology.md §1:

Тезисы:

• «Секция — открытый разговор, вести его должен кандидат» — дословно совпадает с яндексовским «кандидат — основной участник беседы». Два независимых источника = это правило железное.
• SDP добавляет к этапу 1 вопрос, которого нет в яндекс-диалоге явно: read/write ratio — на секции говорить его сразу после RPS (наш эталон URL shortener: 100:1).
• Step 2 «Justify your ideas» — обосновывать каждый блок, а не рисовать молча; совпадает с яндексовским «ясно и аргументированно выражать мнение».
• Back-of-envelope SDP относит к приложению: powers of two + latency numbers → наш KB §1–2 (выучить до автоматизма).

Источники: SDP — How to approach; Palantir: How to rock a systems design interview; HiredInTech: The system design interview; видео Gabbard из further reading SDP — наш конспект jackson-gabbard-ep06.md (45.9).

2. Базовые трейдоффы: performance/scalability, latency/throughput

• Performance vs scalability: «performance-проблема — система медленная для одного пользователя; scalability-проблема — быстрая для одного, но медленная под нагрузкой». Система масштабируема, если производительность растёт пропорционально добавленным ресурсам (определение из A word on scalability, CTO AWS).
• Latency vs throughput: latency — время на одно действие, throughput — число действий в единицу времени. Цель: максимальный throughput при приемлемой latency — не наоборот; на секции формулировать цель именно так.
• Availability vs consistency — главная пара, разворачивается в CAP (§3) и паттерны согласования реплик (§4).
• Эти три пары — «язык секции»: любое решение проговариваем в терминах, чем платим (latency? throughput? consistency? availability?).

Источники: SDP — Performance vs scalability; Scalability, availability, stability, patterns (jboner, слайды).

3. CAP, консистентность и честное место PACELC

• CAP: в распределённой системе гарантированы одновременно только два из трёх — Consistency (каждое чтение видит последнюю запись или ошибку), Availability (каждый запрос получает ответ, пусть и не самый свежий), Partition tolerance (система живёт несмотря на сетевые разделения).
• Сеть ненадёжна → P выбирать нельзя, выбирать приходится между C и A — ключевая формулировка источника, брать в речь дословно.
• CP: ожидание ответа партиционированной ноды может кончиться timeout; выбор для бизнеса, где нужны атомарные чтение/запись (деньги, инвентарь).
• AP: ответ от самой доступной ноды, возможно устаревший; записи догоняют после схлопывания раздела; выбор для систем, которые должны работать несмотря на внешние сбои (лента, счётчики).
• PACELC в primere отсутствует — честная пометка: там только CAP. Расширение «при Partition выбираем A или C, Else — Latency или Consistency» брать из DDIA (карта — ../knowledge-base.md §12, конспект — ddia-map.md, 45.10). На секции упоминание PACELC поверх CAP — плюс, но приписывать его primere нельзя.

Паттерны согласования реплик (Consistency patterns) — три уровня:

Источники: CAP theorem revisited; CAP FAQ; Transactions across data centers.

4. Сеть: DNS, CDN, load balancer, reverse proxy

DNS — перевод имени в IP; иерархия авторитативных серверов, резолверы кэшируют с TTL (устаревание из-за propagation). Записи: A — имя→IP, CNAME — имя→имя, NS — DNS-серверы домена, MX — почта. Managed DNS (Route 53, CloudFlare) умеет маршрутизировать трафик: weighted round robin (выводить серверы из-под трафика, баланс кластеров разного размера, A/B), latency-based, geolocation-based.

• Тезис для секции: DNS — это уже слой балансировки, бесплатный и геораспределённый; минусы — задержка на lookup (смягчается кэшем), стейл-кэш, история с DDoS на DNS-провайдеров (Dyn, октябрь 2016 — лёг Twitter для всех, кто не знал IP).

CDN — глобально распределённые прокси, отдают контент ближе к пользователю; выгрыш двойной: пользователю — близкий ДЦ, нашим серверам — минус чужие запросы. Обычно статика (HTML/CSS/JS, фото, видео), но CloudFront умеет и динамику.

• Push CDN: контент заливаем сами при изменении; минимум трафика, максимум хранения; хорош для редких обновлений и малого трафика.
• Pull CDN: тянет с нашего сервера по первому запросу, хранит по TTL; медленнее первый запрос, минимум storage у CDN; хорош под тяжёлый трафик (популярное остаётся в кэше).
• Минусы: цена, стейл до истечения TTL, переписывание URL статики.

Load balancer — раздаёт запросы по вычислительным ресурсам; три главных эффекта: не слать на нездоровые серверы, не перегружать живые, убирать единую точку отказа. Балансировка: random, least loaded, session/cookies, round robin / weighted round robin, L4, L7. Защита самого LB — несколько инстансов в active-passive или active-active.

• L4 решает по транспорту (IP+порт, NAT), пересылает пакеты; L7 читает прикладной слой (заголовки, куки, тело) и может, например, видео гнать на видеосерверы, а биллинг — на усиленные серверы. L4 дешевле по времени/ресурсам, но на современном железе разница с L7 мала.
• Бонусы LB: SSL termination (бэкенд не тратится на шифрование, X.509 не нужен на каждом сервере) и session persistence (куки → один и тот же инстанс, если приложение не хранит сессии).
• Horizontal scaling: клонирование stateless-серверов дешевле и доступнее, чем вертикальный рост на дорогом железе; серверы обязаны быть stateless — сессии в централизованное хранилище (SQL/NoSQL или персистентный кэш Redis/Memcached); по мере роста app-серверов растёт число соединений вниз по стеку (кэши, БД).

Reverse proxy — централизует внутренние сервисы за единым фасадом: безопасность (прячет бэкенд, чёрные списки IP, лимит соединений), SSL termination, компрессия, кэш, отдача статики напрямую. Отличие от LB: LB имеет смысл с несколькими серверами, reverse proxy полезен даже с одним; NGINX/HAProxy умеют и то и другое (L7). Минус общий: дополнительная сложность и потенциальная SPOF, лечится фейловером за цену ещё большей сложности.

Источники: SDP: DNS / CDN / Load balancer / Reverse proxy; Scalability for dummies, часть 1 — Clones; NGINX architecture.

5. Прикладной слой: web/app разделение, микросервисы, discovery

• Web layer ≠ application layer: разделение позволяет масштабировать и конфигурировать слои независимо (новый API → добавить app-серверов, web не трогаем). Принцип единственной ответственности: маленькие автономные сервисы, маленькие команды.
• Workers в app-слое включают асинхронность — тяжёлые операции уходят в фон (связка с очередями, §8).
• Микросервисы: независимо деплоимые маленькие модульные сервисы, каждый — свой процесс, общение через лёгкий механизм; пример источника — Pinterest: user profile, follower, feed, search, photo upload.
• Service discovery: Consul / Etcd / Zookeeper хранят имена-адреса-порты и health checks; у Consul и Etcd внутри KVS для конфигов. На секции называется как ответ на «как сервисы находят друг друга».
• Честный минус (блок Disadvantages): app-слой со слабосвязанными сервисами требует другого подхода к архитектуре/эксплуатации/процессам, микросервисы добавляют сложность деплоя и операций → на секции не пропагандировать микросервисы сразу, а взвешивать (яндексовский KISS).

Источники: Intro to architecting systems for scale (lethain); SDP — Application layer.

6. Хранение: RDBMS, приёмы масштабирования SQL, NoSQL, SQL vs NoSQL

RDBMS и ACID: Atomicity (транзакция всё или ничего), Consistency (валидное состояние → валидное), Isolation (конкурентное выполнение ≈ последовательному), Durability (закоммитил — живёт). Шесть приёмов масштабирования SQL в primere: master-slave, master-master, federation, sharding, denormalization, SQL tuning.

NoSQL — KVS / document / wide column / graph; данные денормализованы, джойны — в приложении, чаще всего без настоящих ACID-транзакций, за eventual consistency. BASE = Basically available, Soft state, Eventual consistency — NoSQL-противовес ACID, выбор availability над consistency.

SQL или NoSQL — критерии выбора (дословные списки источника): SQL — структурированные данные, строгая схема, реляционность, сложные джойны, транзакции, понятные пути масштабирования, зрелость экосистемы, быстрые lookup по индексу. NoSQL — полуструктурированные данные, динамическая схема, нет сложных джойнов, десятки ТБ/ПБ, data-intensive workload, очень высокий IOPS throughput. Данные, хорошо ложащиеся в NoSQL: кликстрим/логи, лидерборды, корзины (временные данные), «горячие» таблицы, lookup-метаданные.

Источники: SDP — Database; Scaling up to your first 10 million users (Harvard, видео); The magic of consistent hashing; NoSQL survey + decision guidance. Связь: ../knowledge-base.md §3 (классы хранилищ), §5–6 (репликация/шардирование), §7 (консистентность); стилевое совпадение со статьёй Яндекса про «свойства и гарантии важнее названий» — конспект yandex-564132.md §3.3.

7. Кэш

• Зачем: неравномерность нагрузки — БД любит равномерные read/write по партициям, а популярные предметы перекашивают распределение; кэш перед БД глотает пики.
• Уровни: клиент (браузер/ОС) → CDN → web-сервер/reverse proxy (Varnish) → БД (собственные кэши) → application cache (Memcached/Redis между приложением и хранилищем). Redis сверх Memcached: персистентность и структуры (sorted sets, lists). Вытеснение — LRU и подобные. Файловый кэш избегать — ломает клонирование и автоскейлинг.
• Что кэшировать: два уровня — запросы к БД и объекты. Кэш запросов (hash запроса → результат) хрупок: сложно инвалидировать, изменение ячейки = инвалидация всех запросов с ней. Объектный кэш — данные как объекты: сессии пользователей, полностью отрендеренные страницы, activity streams, граф данных пользователя.
• Стратегии обновления (главная таблица primere по кэшу):

• Общий минус блока: инвалидация кэша — сложная проблема, нужна консистентность кэша с источником правды, приложение меняется.

Источники: SDP — Cache; From cache to in-memory data grid (Hazelcast, слайды); AWS ElastiCache strategies. Связь: ../knowledge-base.md §4; в эталонах (classic-designs.md) кэш-асайд с TTL — дефолтный выбор везде.

8. Асинхронность: очереди, task-очереди, back pressure

• Зачем: дорогие операции уводим из инлайна — снижаем время ответа; плюс заранее делаем долгую работу (периодические агрегации).
• Message queue: приложение публикует джобу и сразу сообщает пользователю статус; воркер забирает, обрабатывает, сигналит завершение. Пример источника: твит мгновенно появляется в своей ленте, а разнос подписчикам доезжает позже. Выбор брокера по primere: Redis — просто, но сообщения могут теряться; RabbitMQ — популярен, но AMQP и свои ноды; SQS — managed, но бывает высокая latency и возможна доставка дважды (признавать и обрабатывать дубликаты).
• Task queue: принимает задачи с данными, запускает, отдаёт результаты; планирование, тяжёлые фоновые джобы; пример — Celery (в основном Python).
• Back pressure: если очереди растут больше памяти → cache misses, диски, падение throughput. Лечится ограничением размера очереди: заполнена — клиенту 503/server busy, retry с exponential backoff. Это прямая связка с яндексовским «что жертвуем при превышении нагрузки в разы/порядки» (этап 5).
• Честный минус: дешёвые вычисления и real-time потоки лучше синхронно — очереди добавляют задержку и сложность.

Источники: SDP — Asynchronism; Applying back pressure when overloaded; Little's law. Связь: ../knowledge-base.md §8, методичка этап 5 (лайвгард-приёмы).

9. Коммуникация: HTTP, TCP/UDP, RPC vs REST

• HTTP: request/response, самодостаточен — проходит через промежуточные роутеры/LB/кэш/шифрование/компрессию. Таблица глаголов с колонками idempotent/safe/cacheable: GET — да/да/да; POST — нет/нет; PUT — да/нет; PATCH — нет/нет; DELETE — да/нет. Идемпотентность — «можно вызывать много раз без разных последствий» — ключевое слово при разговоре о ретраях (§8 back pressure).
• TCP: соединение с handshake, гарантии доставки в порядке и без порчи (sequence numbers, checksums, ack + ретрансмиссия), flow control и congestion control; цена — задержки и меньшая эффективность. Много открытых соединений = много памяти; connection pooling как лечение. TCP когда: нужна вся доставка целой и утилизация канала по максимуму.
• UDP: без соединения, датаграммы могут потеряться и прийти не по порядку, без congestion control — зато эффективнее; умеет broadcast (DHCP). UDP когда: минимальная latency, «поздние данные хуже потери», свой error-correction. Кейсы: VoIP, видеочат, стриминг, real-time игры. На нашей секции (инстаграм/твиттер): лента и метаданные — TCP/HTTP, live-видео/голос — UDP.
• RPC vs REST: RPC фокусируется на поведении (POST /signup, /addItemToUsersItemsList) — внутренние вызовы, производительность, свои нативные клиенты (Protobuf, Thrift, Avro); REST фокусируется на данных (ресурсы+глаголы: GET/PUT /persons/1234/items) — публичные API, stateless, кэшируемость, горизонтальное масштабирование. Четыре качества REST из источника: ресурсы через URI, действия через представления/глаголы, self-descriptive ошибки (статус-коды), HATEOAS.
• Честные минусы REST: неудобные запросы «за час с фильтрами», множественные round-trips за вложенными данными (боль для мобильных), раздувание payload со временем для старых клиентов. Минусы RPC: тесная связка клиента с реализацией, новая операция = новый API, сложнее отладка и кэширование.

Источники: SDP — Communication; Do you really know why you prefer REST over RPC; Scaling memcache at Facebook. Про TLS в primere нет отдельной секции — только SSL termination на LB/reverse proxy (§4) и базовые правила security (§10): шифровать in transit и at rest.

10. Безопасность (минимум по primere)

• Шифровать in transit и at rest; санитизировать весь пользовательский ввод (XSS, SQL injection), параметризованные запросы; принцип наименьших привилегий. На секции достаточно одной фразы в этапе 5 (эксплуатация) — глубоко не ждут.

Источники: API Security Checklist; OWASP Top Ten.

11. Отказоустойчивость и доступность в цифрах

Два комплементарных паттерна HA: fail-over и replication.

• Fail-over active-passive: active шлёт heartbeats, passive следит; прервался heartbeat — passive забирает IP и сервис. Время простоя = hot standby (уже запущен) vs cold standby (надо поднимать). Синоним — master-slave failover. Active-active: оба держат трафик; для публичных — DNS знает оба IP, для внутренних — логика приложения. Синоним — master-master failover.
• Минусы fail-over (из Disadvantages): больше железа и сложности; возможна потеря данных, если active умер до репликации новых записей.
• Девятки (учить наизусть, KB §1.3 дублирует):

• Последовательные vs параллельные компоненты: в цепочке доступности перемножаются — два компонента по 99.9% дают 99.8% (A_total = A₁ × A₂); параллельно — растут: 1 − (1−0.999)² = 99.9999%. Это формула, которую стоит писать на доске при разговоре про SPOF: каждый обязательный компонент в цепочке снижает итог, репликация параллельной веткой — повышает.

Источники: SDP — Availability patterns; Scalability, availability, stability, patterns. Связь: ../knowledge-base.md §9 (отказоустойчивость), §10 (эксплуатация); методичка этап 5.

12. Real world architectures: системы и уроки (AC #2 этого конспекта)

Инструкция автора к этой секции: «не залипать в деталях», а (1) находить общие принципы, технологии и паттерны, (2) понимать, какую проблему решает каждый компонент, где работает, где нет, (3) выписывать lessons learned.

12.1 Системы, разобранные в primere (по типам)

12.2 Корпоративные архитектуры — что примечательно для наших эталонов

Дословные факты из названий статей primere (не выдумывать сверх):

• Twitter: 150M активных пользователей, 300K QPS, firehose 22 MB/s; 250M твитов в день хранятся в MySQL; 3000 картинок/сек; «Timelines at scale» (InfoQ) — базовая статья про fan-out.
• Instagram: 14M пользователей, терабайты фото (статья 2011) — классика «маленькая команда, Django+Postgres+CDN».
• Facebook: Scaling memcached (NSDI-статья), TAO — distributed data store для соцграфа, photo storage (OSDI), Live на 800K одновременных зрителей.
• WhatsApp: «архитектура, которую Facebook купил за $19B» — эталон минимализма (для секции «мессенджер»).
• Netflix: 360° стека + «что происходит, когда нажимаешь Play» — эталон микросервисов и отказоустойчивости.
• Pinterest: 10+ млрд просмотров/мес; «18M посетителей, рост 10x, 12 сотрудников»; Uber: 2000 инженеров, 1000 сервисов, 8000 репозиториев; Salesforce: 1.3B транзакций/день; TripAdvisor: 40M посетителей, 200M динамических просмотров, 30TB; Tumblr: 15 млрд просмотров/мес; Mailbox: 0→1M пользователей за 6 недель; DataSift: realtime-майнинг на 120K твитов/сек.

12.3 Shared principles — уроки реальных систем (наша выжимка по инструкции источника)

Сам primere принципы не перечисляет (даёт список и инструкцию «identify shared principles») — ниже наша выжимка, проговариваемая на секции как «паттерны, которые повторяются у всех»:

1. Всё платит за что-то осознанно: Dynamo выбрал availability (eventual consistency), Spanner — consistency (заплатил latency и атомными часами), Kafka — throughput через sequential I/O (заплатил лагом). Формулировка для доски: «у каждой системы из списка есть осознанная жертва — называю её».
2. Партиционирование + репликация повсюду: ни одна система из списка не масштабируется одной вертикалью; шардирование данных и реплики — обязательный минимум ответа.
3. Координация — отдельный сервис: Chubby у Google, Zookeeper в Hadoop/Kafka — координация/локи/конфиг вынесены в специализированный компонент; в ответе «кто разрешает конфликты и кто мастер» должен быть выделенный механизм.
4. Append-only лог и sequential I/O как основа: GFS/Bigtable (SSTable + компакция), Kafka — записывают последовательно и компактируют; отсюда же рекомендация из latency-чисел «HDD — только sequential».
5. Кэш — отдельный тир архитектуры, а не фича: Facebook строил отдельную науку вокруг Memcached (инвалидация, репликация кэша, регионы).
6. Наблюдаемость — часть архитектуры: Dapper — трейсинг как отдельная инфраструктура, без которой распределённую систему нельзя эксплуатировать; в этапе 5 называем метрики+трейсинг+логи.
7. Асинхронность по умолчанию для тяжёлых путей: MapReduce/Storm/Spark — сама обработка вынесена из транзакционного пути; лента Twitter — fan-out в фоне.

Источники: SDP — Real world architectures; Twitter timelines at scale (InfoQ). Связь: ../classic-designs.md §2 (лента: fan-out), §3 (мессенджер: WhatsApp-минимализм), §4 (медиа: CDN+шардирование фото); ../knowledge-base.md §11 (что назвать на секции).

13. Вопросы с решениями в primere — меню тренировок

Восемь вопросов с полными разборами в solutions/; наше покрытие:

Полный список «дополнительных вопросов» Appendix уже разобран в sdp-appendix-numbers.md §5 (23 вопроса с приоритизацией под соцсети).

14. Что этот гайд добавляет к нашей базе знаний (карта соответствий)

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

• sdp-appendix-numbers.md — Appendix того же репо (числа, вопросы), TASK-45.6
• yandex-564132.md — формат секции (первоисточник каркаса), TASK-45.5
• ../knowledge-base.md — сжатый рабочий справочник (учить по нему)
• ../methodology.md — каркас ответа и план под слоты
• ../classic-designs.md — эталонные разборы (URL shortener, лента, мессенджер, медиа)