title: Конспект материала 9 — karanpratapsingh/system-design (учебник-репозиторий) source: https://github.com/karanpratapsingh/system-design (один README ~5700 строк; сайт курса karanpratapsingh.com/courses/system-design) author: Karan Pratap Singh; учебник с диаграммами Excalidraw, 5 глав — от основ сети до разборов систем конспект: подготовлено 2026-09-17, TASK-45.13; прочитан полный текст README глав I–V; тезисы — дословная выжимка, формулировки «что проговаривать» — наши дополнения статус: готов к использованию как дополнение к SDP: уникальные темы (типы хранилищ, 2PC/3PC/Sagas, Event Sourcing/CQRS, REST/GraphQL/gRPC, WebSockets/SSE, geohash/quadtree, circuit breaker, rate limiting, SLA/SLO/SLI, RTO/RPO, OAuth/OIDC/SSO/mTLS, разборы Twitter/Netflix/Uber) размечены для переноса в KB §3–§10/§13–§14

Материал 9: karanpratapsingh/system-design — учебник-репозиторий

Структурированный курс по системному дизайну, оформленный как один большой README: сетевые основы → базы данных → архитектурные паттерны → инфраструктурные практики → разборы пяти классических систем (URL shortener, WhatsApp, Twitter, Netflix, Uber). По отношению к нашей подготовке:

• System Design Primer (sdp-guide.md, TASK-45.7) — это «словарь паттернов» с обязательным блоком Disadvantages.
• Этот курс — «линейный учебник с разбором систем» как у Alex Xu; хорошо дополняет SDP деталями, которых в primer нет.
• Приоритет из learn-system-design-index.md: P3, ключевые главы (разборы + распределённые транзакции/реал-тайм транспорт/геоданные) — P2.

Как читать этот конспект: секции 1–4 — быстрый словарь по главам I–IV; секция 5 — фреймворк интервью из главы V; секция 6 — разборы пяти систем с числами и ключевыми решениями; секция 7 — темы, уникальные относительно SDP, с маппингом в базу знаний; секция 8 — сценарии использования.

1. Глава I — Основы: сеть, доступность, масштабирование, хранение

1.1 Сеть (IP, OSI, TCP/UDP, DNS, прокси)

• IP — логический адрес устройства в сети; DNS превращает домен в IP через цепочку root → TLD → authoritative NS, с кэшированием на каждом уровне по TTL.
• OSI — семь уровней абстракции; на собеседовании достаточно проговорить, что HTTP работает поверх TCP (L4), TLS — L6/L7, а Ethernet — L2.
• TCP — надёжная доставка с установлением соединения, порядком и контролем потерь; UDP — быстрый, без гарантий, хорош для стриминга/ real-time.
• Reverse proxy — стоит перед серверами, защищает и балансирует; forward proxy — перед клиентом, часто используется для анонимизации/контроля доступа. Маппинг: вся эта часть уже покрыта knowledge-base.md §13.1 и sdp-guide.md §4 — повторяем только если нужно освежить терминологию.

1.2 Балансировка и кластеризация

• Load balancer распределяет трафик между нодами; в курсе упоминаются Round Robin, Weighted Round Robin, Least Connections, IP-hash (sticky sessions).
• Sticky sessions полезны, когда состояние хранится локально на ноде, но лучше стремиться к stateless-бэкендам и выносить состояние в Redis/БД.
• Clustering — группировка серверов под общим узлом; horizontal scaling = добавление машин, vertical scaling = увеличение ресурсов одной машины. Маппинг: LB-алгоритмы и sticky sessions уже в KB §13.2; разница только в формулировках.

1.3 Кэш и CDN

• Кэширование ускоряет чтение и снижает нагрузку на БД; основные паттерны: cache-aside, write-through, write-around, write-back.
• CDN — распределённая сеть краевых узлов для статики; работает в режимах push (горячий контент проталкиваем), pull (по промаху) и hybrid.
• LRU — рабочая политика вытеснения для большинства сценариев; на секции говорить: «кэшируем горячее, вытесняем редкое». Маппинг: кэш-паттерны есть в SDP; CDN подробнее разобран в KB §13.8 (push/pull/hybrid).

1.4 Доступность и масштабируемость

• Availability измеряется «девятками»: 99 % = 3.65 дня простоя/год, 99.9 % = 8.76 ч, 99.99 % = 52.6 мин, 99.999 % = 5.26 мин.
• High availability обычно достигается избыточностью: несколько инстансов сервисов, read-реплики БД, реплики кэша, несколько ДЦ.
• Scalability — способность системы расти под нагрузку; горизонтальное масштабирование предпочтительнее, потому что дешевле и устраняет единую точку отказа. Маппинг: числа «девяток» и trade-off масштабирования есть в KB §9/§10 и SDP §11.

1.5 Типы хранилищ (block, file, object, HDFS) — уникально vs SDP

• Block storage — сырой доступ к блочным устройствам (SSD/HDD), используется базами данных и файловыми системами; низкий уровень, высокая производительность.
• File storage — иерархия файлов и папок с общим доступом по сети (NFS/SMB); хорош для офисных/legacy-сценариев, плохо масштабируется.
• Object storage — плоское хранилище объектов (ключ → blob + метаданные); масштабируемо, дешево, идеально для медиа/бэкапов (S3, MinIO, GCS).
• HDFS — распределённая файловая система для batch-аналитики; оптимизирована под большие файлы и последовательное чтение, а не произвольный доступ.
• Куда в KB: дополнить knowledge-base.md §3 «Классы хранилищ и критерии выбора» — в текущей версии есть LSM/B-tree, но нет четырёх уровней абстракции хранения.

2. Глава II — Базы данных

2.1 SQL vs NoSQL и таксономия NoSQL

• SQL — реляционные БД с ACID, схемой и JOIN; хороши для структурированных данных со сложными связями.
• NoSQL — четыре большие группы: key-value (Redis, DynamoDB), document (MongoDB), wide-column (Cassandra, HBase), graph (Neo4j).
• Выбор между SQL и NoSQL — не вопрос моды, а вопрос структуры данных, требований к консистентности и масштабированию записи. Маппинг: таксономия уже есть в KB §3 и SDP §6; здесь больше иллюстраций и названий.

2.2 Репликация, индексы и нормализация

• Репликация повышает отказоустойчивость и масштабирует чтение; модели: master-slave (async/sync), master-master, каскадная.
• Индексы ускоряют чтение за счёт замедления записи; B-tree — универсальный, hash — точное совпадение, clustered — физический порядок строк.
• Нормализация убирает избыточность (1NF–3NF/BCNF); денормализация добавляет избыточность ради скорости чтения — типичный trade-off высоконагруженных систем. Маппинг: индексы и нормальные формы не разбираются в SDP; стоит добавить в KB §3.1/§6 как «DB internals для секции».

2.3 ACID, BASE и транзакции

• ACID — атомарность, консистентность, изолированность, долговечность; стандарт реляционных баз.
• BASE — Basically Available, Soft state, Eventual consistency; модель NoSQL под высокую доступность и partition tolerance.
• Уровни изоляции от младшего к старшему: read uncommitted → read committed → repeatable read → serializable; чем выше, тем медленнее. Маппинг: ACID/BASE и уровни изоляции уже в KB §7 (с подробностями из DDIA); здесь компактное повторение.

2.4 CAP и PACELC

• CAP: при сетевом разделении (P — неизбежно) выбираем между C (консистентность) и A (доступность); в одном ДЦ обычно C, между ДЦ — AP с eventual consistency.
• PACELC мягче CAP: даже без разделения (Else) выбираем между Latency и Consistency; строгая консистентность стоит дополнительного round-trip.
• Практический вывод: большинство web-систем живут в AP с eventual consistency и асинхронной сверкой; строгую CP-зону оставляют деньгам/остаткам, где отдать неверное дороже, чем молчать. Маппинг: PACELC уже упомянут в SDP и развёрнут в KB §7; курс даёт только короткую, но чёткую формулировку.

2.5 Распределённые транзакции: 2PC, 3PC, Saga — уникально vs SDP

• 2PC (Two-Phase Commit): фаза prepare → фаза commit; даёт атомарность, но координатор — точка блокировки и отказа; непопулярен в высоконагруженных системах.
• 3PC добавляет фазу pre-commit и таймауты, чтобы уменьшить блокировки, но усложняет протокол и не устраняет все краевые случаи.
• Saga — последовательность локальных транзакций с компенсациями; оркестрация (центральный координатор) vs хореография (события между сервисами); выбор для микросервисов.
• Transactional outbox (упоминается в связке): событие пишется в таблицу outbox в той же транзакции, воркер/CDC отправляет в Kafka — надёжная публикация. Маппинг: KB §7 уже содержит 2PC/Saga/outbox; курс добавляет 3PC и короткую интуицию — можно использовать как дополнительную цитату.

2.6 Шардирование, консистентное хэширование и федерация

• Шардирование разбивает данные по нескольким нодам; схемы: hash-based, list-based, range-based, composite.
• Consistent hashing снижает перешардирование при добавлении/удалении нод: теряем только 1/n ключей вместо почти всех.
• Federation (функциональный/вертикальный шард) — разделение по таблицам/сервисам, а не по строкам; первый шаг перед горизонтальным шардированием. Маппинг: шардирование и consistent hashing есть в SDP и KB §6; federation — небольшое дополнение.

3. Глава III — Архитектурные паттерны

3.1 N-tier, монолит и микросервисы

• N-tier — классическое разделение на presentation / application / data tier; просто, но плохо масштабируется независимо.
• Монолит — единый деплойный артефакт; быстрая разработка на старте, но сложный рост команды и независимого масштабирования.
• Микросервисы — сервисы с собственной бизнес-способностью и БД; цена — network latency, distributed complexity, observability. Маппинг: монолит/микросервисы разобраны в SDP §5; N-tier — дополнение, полезное для формулировки «почему не трёхзвенка».

3.2 Очереди, брокеры, pub-sub, ESB, EDA

• Message queues (Kafka, RabbitMQ, SQS) развязывают (decouple) отправителя и получателя; гарантируют durability, часто at-least-once доставку.
• Pub-sub — один продюсер, много консьюмеров; хорошо для уведомлений, лент, fan-out событий.
• ESB (Enterprise Service Bus) — центральная шина маршрутизации/трансформации сообщений между сервисами; увеличивает coupling, уступает место лёгким event-брокерам.
• EDA (Event-Driven Architecture) — сервисы реагируют на события, а не синхронно вызывают друг друга; плюс — слабое связывание, минус — сложность отладки и ordering. Маппинг: ESB/EDA почти не разбираются в SDP; стоит добавить в KB §8/§10 как паттерны интеграции.

3.3 Event Sourcing и CQRS — уникально vs SDP

• Event Sourcing: состояние приложения хранится не как текущий срез, а как неизменяемый лог событий; источник правды — события, срезы можно строить повторно.
• CQRS (Command Query Responsibility Segregation): модели записи и чтения разделены; команды изменяют агрегат, запросы читают оптимизированные projections.
• Event Sourcing + CQRS часто идут вместе, но не обязаны; плата — сложность схемы, версионирование событий, необходимость snapshot'ов.
• Когда применять: финансовые аудит-логи, сложные домены с требованием «перемотать состояние». Маппинг: темы отсутствуют в SDP и в KB; добавить в KB §10 «Паттерны надёжности и сложных доменов» или отдельный §.

3.4 API Gateway и BFF

• API Gateway — единая точка входа: TLS termination, auth, rate limiting, routing, request/response transformation, caching.
• BFF (Backend for Frontend) — отдельный бэкенд под конкретный клиент (web/mobile/TV), который агрегирует вызовы к микросервисам.
• Gateway решает cross-cutting concerns; BFF решает разницу в потребностях клиентов; иногда совмещаются. Маппинг: API Gateway уже в KB §13.8; BFF — дополнение к шлюзу.

3.5 REST, GraphQL и gRPC — уникально vs SDP

• REST — ресурсный HTTP-стиль, простой и универсальный; плюс — кэширование и человекочитаемость, минус — over-fetching/under-fetching.
• GraphQL — клиент запрашивает ровно нужные поля; плюс — гибкость фронтенда, минус — сложность кэширования, N+1 запросы, rate limiting.
• gRPC — бинарный RPC поверх HTTP/2 с protobuf; плюс — высокая производительность и контракты, минус — меньшее удобство для браузеров.
• На секции: внешние API — REST/GraphQL, межсервисный трафик — gRPC; WebSocket/gRPC streaming — для real-time. Маппинг: SDP §9 сравнивает HTTP и RPC, но не GraphQL; добавить в KB §10/§13.7 как выбор протокола.

3.6 Real-time транспорт: long polling, WebSockets, SSE — уникально vs SDP

• Long polling — клиент держит HTTP-соединение открытым, пока сервер не пришлёт данные; простой, но накладные ресурсы на поддержание множества висящих соединений.
• WebSockets — полнодуплексное соединение после handshake; лучший выбор для мессенджеров, коллаборативных редакторов, live-обновлений.
• SSE (Server-Sent Events) — однонаправленный сервер → клиент поверх HTTP; проще WebSocket, хорош для лент/нотификаций; авто-reconnect и совместимость с HTTP-инфраструктурой. Маппинг: уже есть в KB §13.3 в виде таблицы; курс — дополнительный источник формулировок.

4. Глава IV — Практика: геоданные, отказоустойчивость, security, эксплуатация

4.1 Geohashing и Quadtrees — уникально vs SDP

• Geohash — кодирование lat/long в Base-32 строку; иерархический префикс позволяет искать «ближайшие» сравнением строк (например, Сан-Франциско → 9q8yy9mf).
• Quadtree — рекурсивное разбиение 2D-пространства на 4 квадранта; листья хранят объекты, внутренние узлы — границы; идеален для range-запросов «объекты внутри прямоугольника».
• Практика Uber: хранить последние позиции водителей в памяти (Redis) + перестраивать Quadtree при обновлении; Hilbert-кривая помогает эффективным range-запросам. Маппинг: KB §13.6 упоминает geohash/Quadtree/R-деревья; курс даёт детали, которые стоит туда добавить.

4.2 Circuit breaker — уникально vs SDP

• Circuit breaker защищает от каскадных отказов: Closed (норма) → Open (отказ, быстрый reject) → Half-Open (пробный запрос).
• Вместо того чтобы «зависать» на упавшей зависимости, клиент получает быстрый fallback и не исчерпывает пул соединений.
• Параметры: порог ошибок, таймаут окна, cooldown до half-open, monitored rolling window. Маппинг: в KB §9 есть timeouts/retries/backpressure, но circuit breaker не выделен; добавить как обязательный паттерн отказоустойчивости.

4.3 Rate limiting: алгоритмы — уникально vs SDP

• Token bucket — равномерное пополнение токенов; подходит для burst-трафика с ограничением средней скорости.
• Leaky bucket — фиксированная скорость выхода; сглаживает пики, но может задерживать допустимые burst'ы.
• Fixed window — простой счётчик в интервале; проблема «пик на границе окна».
• Sliding window log / counter — точнее, но дороже по памяти; sliding window log хранит timestamps, counter — аппроксимация. Маппинг: KB §14.1 уже разбирает алгоритмы на основе Alex Xu; курс — дополнительная выжимка для повторения.

4.4 Service discovery

• Сервисы в динамическом окружении регистрируются в service registry (Consul, Eureka, ZooKeeper, etcd); клиенты запрашивают адрес перед вызовом.
• Два подхода: client-side discovery (клиент сам ходит в registry) и server-side discovery (через LB/gateway).
• Registry автоматически выкидывает нездоровые инстансы по health checks/TTL; в Kubernetes сервис-дискавери встроено (Service + DNS + readiness probes). Маппинг: уже покрыто SDP §5 и KB §10; здесь только контекст в разборе систем.

4.5 SLA, SLO, SLI — уникально vs SDP

• SLA (Service Level Agreement) — внешнее обещание перед пользователями/клиентами; нарушение = штрафы/компенсации.
• SLO (Service Level Objective) — внутренняя цель, которую команда ставит себе, чтобы не нарушить SLA с запасом.
• SLI (Service Level Indicator) — конкретная метрика (latency p99, availability, error rate, throughput), по которой измеряем SLO.
• Формула для секции: «SLI → SLO → SLA; SLO всегда строже SLA, чтобы оставался буфер». Маппинг: отсутствует в SDP; добавить в KB §10 «Эксплуатация».

4.6 Disaster recovery: RTO и RPO — уникально vs SDP

• RTO (Recovery Time Objective) — максимально допустимое время простоя после аварии; определяет горячий/тёплый/холодный standby.
• RPO (Recovery Point Objective) — максимально допустимая потеря данных; определяет частоту бэкапов/репликации.
• Стратегии: backup & restore (длинный RTO/RPO), pilot light, warm standby, hot standby/multi-site active-active. Маппинг: отсутствует в SDP; добавить в KB §9/§10 как язык отказоустойчивости.

4.7 Виртуализация и контейнеризация

• VM — полная изоляция ОС, тяжелее по ресурсам, запуск в минуты; контейнеры — shared kernel, лёгкие, запуск в секунды.
• Kubernetes/orchestrators решают вопросы масштабирования, rolling update, самовосстановления и service discovery.
• Когда что выбирать: контейнеры — стандарт для микросервисов и CI/CD (быстрый деплой, плотность упаковки); VM — когда нужна жёсткая изоляция или legacy-стек. Маппинг: высокоуровневое повторение; в KB не нужно дублировать.

4.8 Security: OAuth 2.0, OIDC, SSO, mTLS — уникально vs SDP

• OAuth 2.0 — делегированный доступ: клиент получает access token от authorization server, ресурсный сервер проверяет его.
• OIDC — слой идентификации поверх OAuth 2.0; возвращает ID token (JWT) с claims о пользователе.
• SSO — единый вход через центральный IdP; удобство для пользователей, но IdP становится критичной точкой.
• mTLS — взаимная TLS-аутентификация сервисов; стандарт для zero-trust в микросервисах. Маппинг: KB §13.7 упоминает OAuth 2.0/JWT; OIDC/SSO/mTLS — расширение security-блока.

5. Глава V — Фреймворк системного дизайна

Автор предлагает 4 шага, которые затем повторяются в каждом разборе системы. Это западный каркас; сверка с methodology.md §1:

Ключевые тезисы:

• «Не молчи и не рисуй схему без контекста» — на каждом шаге нужно объяснять интервьюеру, почему выбран именно этот компонент.
• Оценки — это не точная наука, а проверка масштаба: RPS, storage и bandwidth нужны, чтобы показать, что мы понимаем нагрузку, а не для точного числа.
• Единый шаблон разбора позволяет не теряться: сначала требования, потом цифры, потом схема, потом детали. Маппинг: фреймворк уже отражён в methodology.md §1; этот курс — дополнительная иллюстрация из устного стиля.

6. Разборы систем: общий шаблон и что в них есть

Все пять разборов (URL Shortener, WhatsApp, Twitter, Netflix, Uber) следуют одному шаблону:

1. Requirements (functional / non-functional / extended)
2. Estimation (DAU, RPS, storage/day, storage/10y, bandwidth)
3. Data model (таблицы / NoSQL-решения)
4. API design (методы и параметры)
5. High-level design (сервисы, связи, кэш, очереди)
6. Detailed design (шардирование, кэш, real-time, безопасность)
7. Bottlenecks (single points of failure, LB, реплики, кэш-реплики, messaging)

Ниже — готовые «заготовки для секции»: масштабные цифры и ключевые решения, которые можно быстро вспомнить перед слотом.

6.1 URL Shortener

• Масштаб: 100M новых URL/месяц → 40 writes/s, 100:1 read/write → 4K reads/s; 6TB storage за 10 лет; 35GB кэша на 20% hot reads.
• Ключ генерации: base62 даёт 62^7 ≈ 3.5T комбинаций; MD5 страдает коллизиями; лучше — Key Generation Service (KGS) с предварительно сгенерированными ключами (два пула: available / used).
• Архитектура: API → KGS → write DB + cache; read идёт сначала в cache, при miss — в БД, затем 301 redirect.
• Масштабирование и extended: шардирование по hash/range + consistent hashing, LRU-кэш; expired-ссылки — active (cron-cleanup) или passive (по обращению); API key для rate limiting, таблица permissions для private URL, метрики просмотров (страна, платформа). Маппинг: URL shortener — эталон classic-designs.md §1 и knowledge-base.md §2.2; курс добавляет детали KGS и cleanup.

6.2 WhatsApp

• Масштаб: 50M DAU × 40 сообщений = 2B сообщений/день → 24K RPS; 5% медиа → 100M файлов/день; 10.2TB/день, 38PB/10лет; bandwidth 120MB/s.
• Сервисы: User Service (HTTP), Chat Service (WebSockets + cache активных сессий), Notification Service, Presence Service (last seen), Media Service.
• Real-time и presence: WebSocket — полнодуплекс, минимальная latency (long polling — fallback с лишней нагрузкой; SSE не подходит — нужен duplex); last seen — heartbeat или lazy update по последнему действию, хранение userId → timestamp в Redis/Memcached.
• Notifications: если получатель offline — событие в очередь (Kafka/SQS/RabbitMQ); Notification Service шлёт через FCM/APNS; очередь даёт ordering и at-least-once.
• Read receipts: доставка — deliveredAt после ACK от клиента; прочитано — seenAt при открытии чата. Маппинг: мессенджер разобран в classic-designs.md §3; курс даёт готовые API и выбор real-time транспорта.

6.3 Twitter

• Масштаб: 200M DAU × 5 твитов = 1B твитов/день → 12K RPS; 10% медиа → 100M файлов/день; ~5.1TB/день, ~19PB/10лет; bandwidth ~60MB/s. (В курсе есть опечатка: в тексте DAU 200M, в summary-таблице 100M; на секции согласовываем с интервьюером.)
• Сервисы и social graph: User, Tweet, Newsfeed, Search, Media, Notification, Analytics; mutual friends/рекомендации — графовая БД (Neo4j/ArangoDB) + ML.
• Лента: три модели — pull (fan-out on read, меньше writes, но высокая latency), push (fan-out on write, быстрое чтение, но взрыв writes для знаменитостей), hybrid (push для обычных, pull для знаменитостей).
• Ranking и retweets: классический EdgeRank — Rank = Affinity × Weight × Decay, сейчас ML-модели; ретвит — запись с type = tweet и content = originalTweetID (или отдельная таблица).
• Search/Trending: Elasticsearch для полнотекста; trending — кэш частых запросов/hashtags с пересчётом batch-job; аналитика — Spark. Маппинг: лента новостей — эталон classic-designs.md §2; курс добавляет push/pull/hybrid и EdgeRank.

6.4 Netflix

• Масштаб: 200M DAU × 5 видео = 1B просмотров/день; read/write 200:1 → 5M uploads/день; 12K RPS; 500TB/день, ~1825PB/10лет; bandwidth 5.8GB/s.
• Pipeline обработки видео: File Chunker (Netflix — по сценам, не по timestamps) → Content Filter (ML: copyright/NSFW, DLQ) → Transcoder (FFmpeg/MediaConvert) → Quality Conversion (4K/1440p/1080p/720p) → object storage (S3).
• Стриминг: CDN + Netflix Open Connect (OCA-устройства у ISP, 95% трафика, failover на серверы Netflix); adaptive bitrate через HLS/DASH; resume — offset из views.
• Поиск, рекомендации, geo-blocking: Elasticsearch для поиска; collaborative filtering + собственный движок (профиль, поведение, устройство, время, запросы); локация по IP/настройкам + CloudFront geo restrictions или Route53 geolocation routing. Маппинг: медиа-хостинг — эталон classic-designs.md §4; курс добавляет Open Connect, scene-based chunking и video pipeline.

6.5 Uber

• Масштаб и сервисы: 100M DAU, 1M водителей, 10M поездок/день; 10 действий/пользователя → 1B запросов/день → 12K RPS; 400GB/день, 1.4PB/10лет; bandwidth 5MB/s; сервисы — Customer, Driver, Ride (matching + quadtree), Trip, Payment, Notification, Analytics.
• Real-time location: WebSocket — лучший выбор (full-duplex, низкая latency); SSE — только сервер→клиент; long polling — fallback с избыточной нагрузкой; фоновое обновление GPS, когда приложение свёрнуто.
• Ride matching: SQL box-запрос не масштабируется → geohash (Base-32, иерархический префикс) → Quadtree (рекурсивное 2D-разбиение, обновление в памяти, Redis-кэш, Hilbert curve для range queries).
• Race conditions, ranking, surge: подбор под mutex, каждое действие — транзакция; после подбора — ranking водителей по рейтингу/отзывам; при высоком спросе — surge pricing (динамическое повышение цены).
• Payments, notifications, bottlenecks: внешний процессор (Stripe/PayPal) + webhook + idempotency key; уведомления через Kafka/NATS (ordering, at-least-once); отказоустойчивость — инстансы сервисов, LB, read-реплики БД, реплики кэша. Маппинг: Uber — не разобран в classic-designs.md, ближайший аналог — гео/карты из KB §13.6; курс даёт полный разбор для западного интервью.

7. Уникальное относительно System Design Primer — карта для переноса в KB

Ниже темы, которые в sdp-guide.md (и в исходном primer) либо отсутствуют, либо даны существенно короче. Для каждой указано: где в этом конспекте, куда в knowledge-base.md идёт перенос, и есть ли там уже заготовка.

Что НЕ уникально vs SDP (и не требует переноса):

• Сеть (IP, DNS, TCP/UDP, прокси) — SDP §4, KB §13.1.
• LB-алгоритмы, sticky sessions — SDP, KB §13.2.
• Кэш-паттерны и CDN — SDP, KB §4/§13.8.
• Доступность «девятками», horizontal/vertical scaling — SDP §11, KB §9/§10.
• SQL vs NoSQL, репликация, шардирование, consistent hashing — SDP §6, KB §5/§6.
• ACID/BASE, CAP/PACELC — SDP §3, KB §7.
• Service discovery — SDP §5, KB §10.
• API Gateway — SDP/инфографика, KB §13.8.
• Message queues / pub-sub — SDP §8, KB §8.
• Монолит vs микросервисы — SDP §5.

8. Как использовать в подготовке

• Если осталось <2 часов до секции: пробежать §6 (разборы систем) и §7 (уникальные темы) — быстро вспомнить числа и ключевые слова.
• Если 1–2 дня: перечитать §2.5 (2PC/3PC/Saga), §3.3 (Event Sourcing/CQRS), §3.5–3.6 (REST/GraphQL/gRPC/WebSockets/SSE), §4.1 (geohash/quadtree) — темы, которые могут встретиться в вопросах «а что ещё знаешь?».
• Если есть время на глубину: сверять каждый разбор с classic-designs.md и knowledge-base.md, чтобы ответы звучали в рамках нашего фреймворка (methodology.md §1), а не как список фактов.
• Что брать на доску: цифры из разборов (RPS/storage/bandwidth), push/pull/hybrid для лент, scene-based chunking для видео, Quadtree/geohash для гео, circuit breaker + rate limiting для отказоустойчивости.

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

• learn-system-design-index.md — индекс подборки learn-system-design, откуда взят этот материал (TASK-45.12)
• sdp-guide.md — System Design Primer, основной гайд (TASK-45.7)
• ../knowledge-base.md — база знаний; целевые разделы для переноса уникальных тем — в таблице §7 этого конспекта
• ../methodology.md — методичка секции; фреймворк из главы V сверяется с §1
• ../classic-designs.md — эталонные разборы URL shortener, ленты, мессенджера и медиа-хостинга
• ../brief.md — бриф из 12 разделов; помогает проверить, что все темы из курса укладываются в программу