---
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 (4 шага) | Яндекс (5 этапов, methodology §1) | Ключевые вопросы SDP |
|---|---|---|
| Step 1: Outline use cases, constraints, assumptions | Этап 1. Уточнение задачи | Кто пользователь? Сколько данных? RPS? **Read/write ratio?** |
| Step 2: High level design | Этап 2. Потоки данных, API, блоки | Схема главных компонентов + **обоснование каждого** («Justify your ideas») |
| Step 3: Design core components | Этап 3. Детальная схема | Хэш+хранилище, коллизии, SQL vs NoSQL, схема БД (пример Pastebin) |
| Step 4: Scale the design | Этапы 4–5. Ресурсы + топология/эксплуатация | LB, горизонтальное масштабирование, кэш, шардирование; bottlenecks + trade-offs |

Тезисы:

- **«Секция — открытый разговор, вести его должен кандидат»** — дословно совпадает с яндексовским «кандидат — основной участник беседы». Два независимых источника = это правило железное.
- 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](https://github.com/donnemartin/system-design-primer#how-to-approach-a-system-design-interview-question); [Palantir: How to rock a systems design interview](https://web.archive.org/web/20210505130322/https://www.palantir.com/2011/10/how-to-rock-a-systems-design-interview/); [HiredInTech: The system design interview](http://www.hiredintech.com/system-design/); видео Gabbard из further reading SDP — наш конспект `jackson-gabbard-ep06.md` (45.9).

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

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

Источники: [SDP — Performance vs scalability](https://github.com/donnemartin/system-design-primer#performance-vs-scalability); [Scalability, availability, stability, patterns (jboner, слайды)](http://www.slideshare.net/jboner/scalability-availability-stability-patterns/).

## 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) — три уровня:

| Паттерн | После записи чтение… | Репликация | Где встречается | Хорош для |
|---|---|---|---|---|
| Weak | может и не увидеть (best effort) | — | memcached, VoIP/видеочат/real-time игры | потеря куска разговора не фатальна |
| Eventual | увидит «в конце концов» (обычно мс) | асинхронная | DNS, email | высокодоступные системы |
| Strong | увидит сразу | синхронная | файловые системы, RDBMS | транзакции |

Источники: [CAP theorem revisited](https://robertgreiner.com/cap-theorem-revisited/); [CAP FAQ](https://github.com/henryr/cap-faq); [Transactions across data centers](http://snarfed.org/transactions_across_datacenters_io.html).

## 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](https://github.com/donnemartin/system-design-primer#domain-name-system) / [CDN](https://github.com/donnemartin/system-design-primer#content-delivery-network) / [Load balancer](https://github.com/donnemartin/system-design-primer#load-balancer) / [Reverse proxy](https://github.com/donnemartin/system-design-primer#reverse-proxy-web-server); [Scalability for dummies, часть 1 — Clones](https://web.archive.org/web/20220530193911/https://www.lecloud.net/post/7295452622/scalability-for-dummies-part-1-clones); [NGINX architecture](https://www.nginx.com/blog/inside-nginx-how-we-designed-for-performance-scale/).

## 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)](http://lethain.com/introduction-to-architecting-systems-for-scale); [SDP — Application layer](https://github.com/donnemartin/system-design-primer#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.

| Приём | Суть | Платим |
|---|---|---|
| **Master-slave** | мастер пишет и читает, слейвы только читают (можно деревом); при смерти мастера — read-only до промоции слейва | логика промоции слейва |
| **Master-master** | оба пишут и читают, координируют записи; переживают падение любого мастера | LB или логика выбора мастера записи; чаще loose consistency или рост write-latency; конфликт-резолюшн с ростом числа пишущих нод |
| **Federation** (функциональное партиционирование) | разнос БД по функциям: forums / users / products; меньше трафика на каждую, больше влезает в память, параллельная запись | не работает, если схема требует «гигантских» функций; джойны между БД сложнее |
| **Sharding** | каждая БД держит подмножество данных; меньше трафика/репликации, больше cache hits, меньше индексы; падение шарда не роняет остальных (но нужна репликация против потери данных) | логика шардинга в приложении, сложные запросы; **скошенное распределение** (power users на шарде), ребалансировка — через **consistent hashing**; джойны через шарды |
| **Denormalization** | избыточные копии против дорогих джойнов (материализованные вьюхи в PG/Oracle); в большинстве систем чтения превосходят записи **100:1–1000:1** | дублирование данных; constraints для синхронизации копий; под тяжёлой записью может стать хуже нормализованной |
| **SQL tuning** | benchmark (ab) + profile (slow query log); CHAR вместо VARCHAR для фиксированных полей, TEXT для больших текстов, INT до 2^32 (~4 млрд), **DECIMAL для денег**, избегать больших BLOB (хранить ссылку), NOT NULL ускоряет поиск; индексы — **B-tree**, O(log n) поиск/вставка/удаление, ускоряют колонки из SELECT/GROUP BY/ORDER BY/JOIN, но едят память и замедляют записи; горячие места — в отдельную таблицу (partitioning) | индексы = память + цена записи; query cache иногда вредит |

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

| Тип | Абстракция | Свойства | Применение |
|---|---|---|---|
| **Key-value store** | hash table | O(1) чтение/запись, память или SSD, ключи в лексикографическом порядке → диапазоны | простые модели, быстро меняющиеся данные, кэш-слой; основа document/graph |
| **Document store** | KVS + документы (XML/JSON/binary) значением | запросы по внутренней структуре документа; MongoDB/CouchDB дают SQL-like язык, DynamoDB — и KVS, и документы | гибкость, occasionally-changing данные |
| **Wide column store** | `ColumnFamily<RowKey, Columns<ColKey, Value, Timestamp>>` | колонки с версиями (timestamp для конфликтов); Bigtable → HBase, Cassandra; ключи в лексикографическом порядке → выборочные диапазоны; HA + масштабируемость | очень большие датасеты |
| **Graph DB** | граф: нода = запись, дуга = связь | оптимизированы под сложные связи и many-to-many; Neo4j, FlockDB (Twitter) | соцграф; минусы: молодые, инструменты беднее, часто только REST |

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

Источники: [SDP — Database](https://github.com/donnemartin/system-design-primer#database); [Scaling up to your first 10 million users (Harvard, видео)](https://www.youtube.com/watch?v=kKjm4ehYiMs); [The magic of consistent hashing](http://www.paperplanes.de/2011/12/9/the-magic-of-consistent-hashing.html); [NoSQL survey + decision guidance](https://medium.com/baqend-blog/nosql-databases-a-survey-and-decision-guidance-ea7823a822d). Связь: `../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 по кэшу):

| Стратегия | Как работает | Минусы (из Disadvantages) |
|---|---|---|
| **Cache-aside** (lazy loading; типично Memcached) | приложение само: промах → БД → в кэш → ответ | промах = 3 хода (задержка); стейл между апдейтами (лечится TTL); новая нода пустая → рост latency |
| **Write-through** | кэш — основное хранилище для записи, кэш синхронно пишет в БД; чтение свежезаписанного быстрое, данные не стейл | запись медленная; много пишем-не-читаем (лечится TTL); новая нода пуста до апдейта (лечится связкой с cache-aside) |
| **Write-behind (write-back)** | запись в кэш, в БД — асинхронно; write-производительность | **потеря данных при падении кэша до записи в БД**; сложнее в реализации |
| **Refresh-ahead** | кэш сам обновляет недавно использованные записи до истечения | промах прогноза = производительность хуже, чем без него |

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

Источники: [SDP — Cache](https://github.com/donnemartin/system-design-primer#cache); [From cache to in-memory data grid (Hazelcast, слайды)](http://www.slideshare.net/tmatyashovsky/from-cache-to-in-memory-data-grid-introduction-to-hazelcast); [AWS ElastiCache strategies](http://docs.aws.amazon.com/AmazonElastiCache/latest/UserGuide/Strategies.html). Связь: `../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](https://github.com/donnemartin/system-design-primer#asynchronism); [Applying back pressure when overloaded](http://mechanical-sympathy.blogspot.com/2012/05/apply-back-pressure-when-overloaded.html); [Little's law](https://en.wikipedia.org/wiki/Little%27s_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](https://github.com/donnemartin/system-design-primer#communication); [Do you really know why you prefer REST over RPC](https://apihandyman.io/do-you-really-know-why-you-prefer-rest-over-rpc/); [Scaling memcache at Facebook](http://www.cs.bu.edu/~jappavoo/jappavoo.github.com/451/papers/memcache-fb.pdf). Про 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](https://github.com/shieldfy/API-Security-Checklist); [OWASP Top Ten](https://www.owasp.org/index.php/OWASP_Top_Ten_Cheat_Sheet).

## 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 дублирует):

| Доступность | Даунтайм/год | Даунтайм/месяц | Даунтайм/неделю | Даунтайм/день |
|---|---|---|---|---|
| 99.9% (three 9s) | 8 ч 45 м 57 с | 43 м 49.7 с | 10 м 4.8 с | 1 м 26.4 с |
| 99.99% (four 9s) | 52 м 35.7 с | 4 м 23 с | 1 м 5 с | 8.6 с |

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

Источники: [SDP — Availability patterns](https://github.com/donnemartin/system-design-primer#availability-patterns); [Scalability, availability, stability, patterns](http://www.slideshare.net/jboner/scalability-availability-stability-patterns/). Связь: `../knowledge-base.md` §9 (отказоустойчивость), §10 (эксплуатация); методичка этап 5.

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

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

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

| Тип | Система | Что это (по primere) | Первоисточник |
|---|---|---|---|
| Data processing | **MapReduce** | распределённая обработка данных, Google | [paper](http://static.googleusercontent.com/media/research.google.com/zh-CN/us/archive/mapreduce-osdi04.pdf) |
| Data processing | **Spark** | распределённая обработка, Databricks | [slides](http://www.slideshare.net/AGrishchenko/apache-spark-architecture) |
| Data processing | **Storm** | потоковая обработка, Twitter | [slides](http://www.slideshare.net/previa/storm-16094009) |
| Data store | **Bigtable** | колоночная распределённая БД, Google | [paper](http://www.read.seas.harvard.edu/~kohler/class/cs239-w08/chang06bigtable.pdf) |
| Data store | **HBase** | open-source Bigtable | [slides](http://www.slideshare.net/alexbaranau/intro-to-hbase) |
| Data store | **Cassandra** | колоночная БД, Facebook | [slides](http://www.slideshare.net/planetcassandra/cassandra-introduction-features-30103666) |
| Data store | **DynamoDB** | документо-ориентированная, Amazon | [Dynamo paper](http://www.read.seas.harvard.edu/~kohler/class/cs239-w08/decandia07dynamo.pdf) |
| Data store | **MongoDB** | документо-ориентированная | [slides](http://www.slideshare.net/mdirolf/introduction-to-mongodb) |
| Data store | **Spanner** | глобально-распределённая БД, Google | [paper](http://research.google.com/archive/spanner-osdi2012.pdf) |
| Data store | **Memcached** | распределённый memory-кэш | [slides](http://www.slideshare.net/oemebamo/introduction-to-memcached) |
| Data store | **Redis** | memory-кэш с персистентностью и типами значений | [slides](http://www.slideshare.net/dvirsky/introduction-to-redis) |
| File system | **GFS** | распределённая ФС, Google | [paper](http://static.googleusercontent.com/media/research.google.com/zh-CN/us/archive/gfs-sosp2003.pdf) |
| File system | **HDFS** | open-source GFS | [apache.org](http://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-hdfs/HdfsDesign.html) |
| Misc | **Chubby** | lock-сервис для слабосвязанных систем, Google | [paper](https://research.google.com/archive/chubby-osdi06.html) |
| Misc | **Dapper** | инфраструктура распределённого трейсинга | [paper](https://research.google.com/pubs/pub36356.html) |
| Misc | **Kafka** | pub/sub очередь, LinkedIn | [slides](http://www.slideshare.net/mumrah/kafka-talk-tri-hug) |
| Misc | **Zookeeper** | централизованная координация и синхронизация | [slides](http://www.slideshare.net/sauravhaloi/introduction-to-apache-zookeeper) |

### 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](https://github.com/donnemartin/system-design-primer#real-world-architectures); [Twitter timelines at scale (InfoQ)](https://www.infoq.com/presentations/Twitter-Timeline-Scalability). Связь: `../classic-designs.md` §2 (лента: fan-out), §3 (мессенджер: WhatsApp-минимализм), §4 (медиа: CDN+шардирование фото); `../knowledge-base.md` §11 (что назвать на секции).

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

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

| Вопрос SDP | Наш статус |
|---|---|
| Design Pastebin.com (or Bit.ly) | покрыт: `classic-designs.md` §1 (URL shortener, эталон Яндекса) |
| Design the Twitter timeline and search (or Facebook feed and search) | покрыт: `classic-designs.md` §2 |
| Design a web crawler | не покрыт — кандидат на тренировочный раунд (очередь + дедуп + politeness) |
| Design Mint.com | не покрыт (агрегация банковских данных; интеграции + нормализация) |
| Design the data structures for a social network | частично: соцграф внутри §2 (flock/graph DB из §6 конспекта) |
| Design a key-value store for a search engine | частично: query cache в §7 |
| Design Amazon's sales ranking by category | не покрыт (агрегации по окнам, top-k) |
| Design a system that scales to millions of users on AWS | собирательный — финальный чек-лист этапов 4–5 |

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

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

| Раздел SDP | Куда легло у нас |
|---|---|
| How to approach (4 шага) | `methodology.md` §1 (6 этапов — яндекс-каркас шире и с таймингом) |
| Performance/scalability, latency/throughput | `knowledge-base.md` §11 (шпаргалка «что назвать») |
| CAP + consistency patterns | KB §7; PACELC — только через DDIA (KB §12) |
| DNS/CDN/LB/reverse proxy | KB §9–10 (топология и эксплуатация, этап 5) |
| Database: 6 приёмов + NoSQL | KB §3, §5, §6 |
| Cache + 4 стратегии | KB §4 |
| Asynchronism + back pressure | KB §8 |
| HTTP/TCP/UDP/RPC/REST | KB §11 (идемпотентность, выбор протокола) |
| Availability patterns, девятки, формулы | KB §1.3, §9 |
| Real world architectures | classic-designs (эталоны) + §12.3 этого файла (уроки) |

---

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

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