---
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:

| Шаг Karan Pratap Singh | Эквивалент в methodology.md | Что делать |
|---|---|---|
| 1. Requirements clarification | Этап 1. Уточнение задачи | Собрать functional / non-functional / extended requirements; зафиксировать масштаб |
| 2. Back-of-envelope estimation | Этап 2. Оценки (часть) | Посчитать DAU, RPS, storage, bandwidth; показать, что понимаем масштаб |
| 3. High-level design | Этап 2–3. API, data model, architecture | Нарисовать блоки, назвать сервисы, обосновать выбор БД/кэша/очереди |
| 4. Detailed design + bottlenecks | Этап 4–5. Детали и эксплуатация | Deep dive: шардирование, кэш, real-time, масштабирование; в конце — bottlenecks и trade-off'ы |

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

- **«Не молчи и не рисуй схему без контекста»** — на каждом шаге нужно объяснять интервьюеру, почему выбран именно этот компонент.
- **Оценки — это не точная наука, а проверка масштаба:** 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` идёт перенос, и есть ли там уже заготовка.

| Тема | В этом конспекте | Целевой раздел KB | Покрытие в KB сейчас |
|---|---|---|---|
| Типы хранилищ (block / file / object / HDFS) | §1.5 | §3 «Классы хранилищ и критерии выбора» | Частично: есть LSM/B-tree, но нет четырёх уровней абстракции. **Добавить.** |
| Индексы (B-tree, hash, clustered) и нормальные формы | §2.2 | §3.1 «Движки хранения» / §6 «Шардирование» | Нет. **Добавить** как «DB internals для секции». |
| 2PC / 3PC / Sagas + transactional outbox | §2.5 | §7 «Консистентность и распределённые транзакции» | Уже есть 2PC/Saga/outbox; 3PC и короткая интуиция — **дополнить.** |
| Event Sourcing и CQRS | §3.3 | §10 «Отказоустойчивость» или новый §«Паттерны сложных доменов» | Нет. **Добавить.** |
| ESB / EDA | §3.2 | §8 «Очереди и потоковая обработка» / §10 | EDA упомянуто обрывками; ESB — нет. **Дополнить.** |
| REST / GraphQL / gRPC — сравнение | §3.5 | §13.7 / §10 | GraphQL не разобран. **Добавить.** |
| Long polling / WebSockets / SSE | §3.6 | §13.3 «Real-time транспорт» | Уже есть таблица; использовать курс как дополнительную формулировку. |
| BFF (Backend for Frontend) | §3.4 | §13.8 / §10 | Нет. **Добавить.** |
| Geohashing и Quadtrees | §4.1 / §6.5 | §13.6 «Гео-шардирование и пространственные данные» | Есть упоминание; детали Base-32, Hilbert, обновление в памяти — **дополнить.** |
| Circuit breaker | §4.2 | §9 «Отказоустойчивость» | Нет. **Добавить.** |
| Алгоритмы rate limiting | §4.3 | §14.1 (Alex Xu Vol. 1) | Уже разобраны; курс — дополнительная тренировка. |
| SLA / SLO / SLI | §4.5 | §10 «Эксплуатация» | Нет. **Добавить.** |
| RTO / RPO и стратегии DR | §4.6 | §9 / §10 | Нет. **Добавить.** |
| OAuth 2.0 / OIDC / SSO / mTLS | §4.8 | §13.7 | OAuth 2.0/JWT есть; OIDC/SSO/mTLS — **дополнить.** |
| N-tier architecture | §3.1 | §10 / §11 | Нет прямого упоминания; **добавить** как антипаттерн при масштабировании. |
| Разборы Twitter, Netflix, Uber | §6.3–6.5 | `classic-designs.md` + KB §11 «что назвать на секции» | Twitter/медиа-хостинг есть; Uber — нет. **Добавить Uber** как пример гео-системы. |

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