--- title: Конспект материала 10 — bregman-arie/system-design-notebook source: https://github.com/bregman-arie/system-design-notebook author: Arie Bregman конспект: подготовлено 2026-09-18, TASK-45.14; прочитаны все 13 md-файлов репо (~1900 строк текста); репо заявлено автором как work-in-progress — много разделов пустые/TODO статус: P3-источник: ценность сосредоточена в упражнениях (особенно AWS-цепочка и stateful-сессии) и нескольких компактных тематических карточках; уникальные микрофакты — см. §6 --- # Материал 10: system-design-notebook — пошаговые карточки + упражнения Репо позиционируется как «step-by-step» обучение System Design. Формат: визуальный индекс тем в корневом README + маленькие страницы по каждой теме + большой блок упражнений/вопросов + несколько разборов систем. Важный нюанс: **автор прямо пишет, что проект незавершён**, и это видно — многие заголовки внутри тем (Consistent Hashing, Sticky Sessions, Health Checks, System Design Process, разборы WhatsApp/Prime Video) помечены TODO или пусты. Поэтому читать нужно выборочно: упражнения и 4–5 заполненных тем. --- ## 1. Структура репо | Блок | Что внутри | Полезность | |---|---|---| | Тематические карточки | Requirements, Basic Architecture, Networking, DNS, Load Balancer, Scalability, Reliability Engineering, API Gateway, Databases, Distributed Systems | Средняя: определения базовые, но есть удачные формулировки (см. §3) | | Exercises / General | ~12 ситуаций «вот схема — найди проблемы и улучши» | Высокая: хороши для самопроверки перед моками | | Exercises / AWS Cloud | Две цепочки: stateless «What time is it?» и stateful «Video Games Shop» | Высокая: показывает эволюцию архитектуры от одного инстанса до multi-AZ | | Questions | Упрощённые вопросы для самопроверки | Средняя; многие без ответов | | System Designs | Big-Scale Monorepo, Parking & Reservation, WhatsApp, Amazon Prime Video | Первая две — полноценны, последние две — только требования/NFR | | Interview Tips | Короткий чек-лист вопросов к себе и интервьюеру | Подтверждает methodology.md §1 | --- ## 2. Тематические карточки — ключевые тезисы ### 2.1 Requirements - **Functional Requirements** — что система должна делать (функции/поведение). Пример для мессенджера: отправка и получение сообщений. - **Non-Functional Requirements** — как система это делает (производительность, доступность, надёжность). Пример: zero downtime, no data loss. - Начинать дизайн с требований — это способ зафиксировать границы и не уйти в оверинжиниринг. *Маппинг: полностью покрыто methodology.md §1 (FR/NFR + вопросы-уточнения).* ### 2.2 Basic Architecture: клиент, сервер, типы серверов - **Client** — любое ПО/устройство, запрашивающее ресурс/сервис у сервера. - **Server** — ПО/железо, предоставляющее ресурс/сервис. - **Bare Metal** — физический сервер, обычно выделенный под одного заказчика/проект. - **Virtual Server** — сервер, поднятый на гипервизоре/облаке. *Маппинг: базовые определения; не требует переноса в KB.* ### 2.3 Networking - **Public IP** — для компонентов, к которым обращаются извне (LB, gateway, публичный веб-сервер). - **Private IP** — для внутренних компонентов, не доступных глобально (бэкенды за LB, внутренние сервисы). - **Latency** — время выполнения одного действия; **Throughput** — число действий в единицу времени. - **L1 cache reference ≈ 0.5 нс, L2 ≈ 7 нс** — разница в 14×. *Маппинг: latency numbers уже в KB §1.2; public/private IP — в §13.1/§13.8.* ### 2.4 DNS - Главная задача — преобразование доменного имени в IP (и обратно). - DNS можно использовать для балансировки нагрузки через **round-robin** записи. - **Подводный камень round-robin DNS**: запись кэшируется с TTL; если нода упала, клиенты продолжают стучаться в мёртвый IP до истечения TTL. ELB/ALB решают проблему. *Маппинг: TTL упомянут в KB §13.1, но питфолл round-robin-as-LB — нет. См. §6.* ### 2.5 Load Balancer - Распределяет задачи по ресурсам; LB — публичный IP, бэкенды — приватные. - Перечислены 9 техник: Round Robin, Weighted RR, Least Connection, Weighted Least Connection, Resource Based, Fixed Weighting, Weighted Response Time, Source IP Hash, URL Hash. - **Недостатки Round Robin**: не знает веса запросов и мощности серверов (может свалить тяжёлые запросы на одну ноду); каждый запрос — новая сессия, плохо для stateful-сценариев. - **Health checks** исключают нездоровые ноды из ротации. - Для e-commerce рекомендуется техника со sticky sessions (если состояние не вынесено в общее хранилище). *Маппинг: §13.2 KB покрывает RR/WRR/Least Connections/Hash/Random; см. §6 про дополнение.* ### 2.6 Scalability - **Vertical Scaling** — наращивание ресурсов существующей ноды (RAM/CPU/диск). Просто, но есть физический потолок и простой при апгрейде; оставляет SPOF. - **Horizontal Scaling** — добавление нод и балансировка между ними. - **Scalability Factor** — отношение прироста нагрузки к приросту ресурсов: - **Linear** — удвоили ресурсы → удвоили нагрузку. - **Sub-linear** — удвоили ресурсы → нагрузка выросла в 1.5× (реалистичный сценарий; коэффициент < 1). - **Supra-linear** — удвоили ресурсы → нагрузка выросла в 3× (коэффициент > 1, редкий оптимум). - **Negative** — удвоили ресурсы → система стала медленнее (коэффициент < 0). *Маппинг: vertical/horizontal — в KB §11; taxonomy scalability factor — **уникально**, см. §6.* ### 2.7 Reliability Engineering - **RAS**: - **Reliability** — вероятность корректной работы системы до момента t. - **Availability** — доля времени, когда система доступна. - **Serviceability** — простота и скорость ремонта/обслуживания (влияет на availability). - **Failover**: - **Cold standby** — резерв включается только после отказа основного. Дешёво, но downtime; трафик за время простоя теряется. Подходит для некритичных сервисов. - **Warm standby** — резерв непрерывно синхронизируется с основным. Проще, но всё ещё возможен downtime и потеря данных. - **Hot standby** — одновременная работа с несколькими инстансами; при отказе одного пользователь не замечает переключения. Дорого; по сути — horizontal scaling. *Маппинг: RTO/RPO и стратегии DR уже размечены karan (TASK-45.13) для KB §9; cold/warm/hot — уточняющая формулировка, см. §6.* ### 2.8 API Gateway - Появился при переходе от монолита к микросервисам: клиентам приходилось ходить во множество сервисов, каждый дублировал monitoring/logging/security. - Преимущества: 1. **Меньше round trips** для клиента (gateway агрегирует вызовы). 2. **Protocol switching** (например, клиент → HTTPS, gateway → HTTP к сервисам). 3. **Offload функций** — rate limiting, logging, auth переносятся в одно место. 4. **Consolidated security** — сервисы открыты только для gateway, единая точка применения политик безопасности. *Маппинг: функции шлюза уже в KB §13.8; origin-story + 4 преимущества — удачная интервью-формулировка, см. §6.* ### 2.9 Databases - **NoSQL** иногда называют «sharded databases»; вызовы — resharding и hotspots. - **Cassandra**: каждая нода может быть primary interface → высокая availability, но постоянная синхронизация снижает consistency. - **Redis**: in-memory KV, single-threaded, использует **I/O multiplexing**, чтобы один поток обслуживал множество соединений; RAM ~100 нс vs SSD ~100 мкс. - **Data Lake**: неструктурированные файлы (JSON/CSV) в object storage; схема накладывается при чтении (schema-on-read). - **Partitioning**: horizontal = одинаковые колонки, разные строки (shard); vertical = разные колонки. - **ACID**: atomicity, consistency, isolation, durability — базовые определения. - **Normalized vs denormalized**: normalized — обновления в одном месте, но joins; denormalized — один lookup, но обновление может требовать скана. - **CAP на примерах**: Cassandra = AP (нет единого мастера, постоянная синхронизация); MongoDB = CP (single master, консистентность, но SPOF). - Выбор БД: тип данных, приоритеты по CAP, access patterns. *Маппинг: классы хранилищ — KB §3; CAP/PACELC — §7/§11; Redis single-threaded+I/O multiplexing — **уникальный микрофакт**, см. §6.* ### 2.10 Distributed Systems - Распределённая система — группа компьютеров, работающих совместно и скрывающих сложность от пользователя. - **Заблуждения/вызовы** (список автора): надёжность сети, нулевая latency, бесконечная bandwidth, меняющаяся топология, безопасность, размер команды. - **Clock drift**: у каждой машины свои часы; рассинхронизация может приводить к непредсказуемому поведению. - **CDN**: географически распределённые edge-серверы для быстрой доставки контента. *Маппинг: partial failure, часы, сеть — KB §9; классические fallacies — **уникально**, см. §6.* --- ## 3. Упражнения и разборы систем ### 3.1 General / Misc — базовая эволюция - Сервер + БД на одной машине → проблемы: SPOF, конкуренция за ресурсы. - Без новых компонентов: vertical scaling (временное решение). - С новыми компонентами: разделить web и DB; добавить LB (но LB — новый SPOF); DNS load balancing как дешёвая альтернатива; round-robin drawbacks; public/private IP; cache; локальная реплика удалённой БД; sticky sessions; health checks; read replica под аналитику. *Маппинг: покрыто KB §4–§6, §9, §13.2; полезно как drill.* ### 3.2 AWS Cloud: «What time is it?» (stateless) Цепочка улучшений: 1. EC2 + Elastic IP — базовая схема. 2. Vertical scaling — при росте пользователей; не масштабируется вечно и даёт простой. 3. Horizontal scaling — добавляем инстансы. 4. Route53 A-record вместо Elastic IP — пользователи ходят по hostname. 5. Проблема DNS: TTL кэширует IP упавшей ноды. 6. ELB + Auto Scaling Group — решает проблему DNS-TTL. 7. Multi-AZ для LB и инстансов; Reserved Instances для предсказуемой базовой нагрузки. *Маппинг: DNS-TTL pitfall — уникальная формулировка для §13.1; остальное стандартно.* ### 3.3 AWS Cloud: «Video Games Shop» (stateful) Проблема: корзина теряется, потому что каждый запрос попадает на разный инстанс. Три решения: 1. **LB sticky sessions** — пользователь прилипает к инстансу. Минус: если инстанс упал, данные потеряны; нагрузка может быть неравномерной. 2. **Client cookies** — клиент носит данные с собой. Минусы: запросы тяжелее; риск подделки cookie. 3. **Server-side session** — session ID в cookie, а данные хранятся в ElastiCache/DynamoDB. Лучший вариант; можно комбинировать с write-through cache+DB. *Маппинг: триада sticky/cookies/server session — **уникально** для KB, см. §6.* ### 3.4 Big-Scale Monorepo (development system design) Задача: `git status` на миллионе файлов занимает секунды/минуты из-за `lstat()` на каждый файл. Решения: - `git fsmonitor` + Watchman — демон кэширует состояние рабочей директории. - `feature.manyFiles=true` — index v4 (path-prefix compression) + `core.untrackedCache`. - `git maintenance` — периодическая оптимизация репо. - Sparse checkout — в рабочей директории только нужные файлы. - Build-system-aware sparse checkout — ещё более узкий набор. *Маппинг: узкая dev-infra тема; не переносим в KB, но оставляем в конспекте как пример «системный дизайн внутри разработки».* ### 3.5 Parking & Reservation System - Уточнения: пользователи, входы/выходы, масштаб. - FR: бронирование места, получение тикета, исключение двойного бронирования, типы ТС, тариф по типу/времени. - Public API: `/reserve`, `/cancel`, `/payment` (внешний процессор). - Internal API: `/calculate_payment`, `/free_spots`, `/allocate_spot`, `/create_account`, `/login`. - Scale предсказуем: ограничен числом парковочных мест. - SQL-схема: Reservations, Garages, Spots, Users, Vehicles. *Маппинг: простейший шаблон разборов (FR/NFR/API/схема/масштаб); повторяет methodology.md §1–§4. Может служить drill-задачей, но не добавляет в KB.* ### 3.6 WhatsApp / Amazon Prime Video - В репо только требования/NFR/API-заготовки; detailed design помечен TODO. Для подготовки лучше использовать `classic-designs.md` §3 (мессенджер) и §4 (видео-хостинг). --- ## 4. Советы по интервью - Выбирай **простейшую архитектуру**, удовлетворяющую требованиям (functional + traffic). - Задавай уточняющие вопросы: требования, как используется, сколько пользователей, как часто, откуда, constraints. - В начале: перечисли фичи, озвучь ожидаемые проблемы и трафик. - На каждом решении называй **pros/cons**. - Проверяй себя: масштабируется ли? есть ли SPOF? *Маппинг: полностью перекрыто methodology.md §1, §5, §7.* --- ## 5. Вердикт: стоит ли тратить время перед слотами 18/21/22.09 - **P3** (фоновое чтение после более плотных источников: KB, DDIA, classic-designs, karan, Polomodov). - **Самое полезное**: две AWS-цепочки (stateless и stateful) как drill на эволюцию архитектуры; формулировка failover cold/warm/hot; scalability factor. - **Самое бесполезное**: пустые TODO-разделы и разборы WhatsApp/Prime Video без деталей. - **Рекомендуемый формат**: пролистать §2–§3 этого конспекта (30 мин) и проработать вопросы из упражнений вслух. --- ## 6. Уникальное относительно существующих материалов — что взять в KB 45.1 Ниже — темы, которых нет (или нет в такой форме) в `knowledge-base.md`, `methodology.md`, `classic-designs.md` и соседних конспектах (TASK-45.5–45.13). Для каждой указан целевой раздел KB. | Тема | Где в этом источнике | Целевой раздел KB | Что в KB сейчас | Решение | |---|---|---|---|---| | **Scalability factor** (linear / sub-linear / supra-linear / negative) | §2.6 | §11 «Мини-шпаргалка», блок «Масштаб» | Нет | **Добавить** строку: «realistic scaling is sub-linear; supra-linear — редкий выигрыш; negative scaling — оверхед > прироста» | | **Fallacies of distributed computing** (network reliability, zero latency, bandwidth, topology change, security, team size) | §2.10 | §9 «Слабые места распределённой среды» | Partial failure, часы, сеть есть, но не в форме «заблуждений» | **Добавить** классические fallacies рядом с partial-failure как интервью-маркер | | **Stateful session triad** (LB sticky sessions / client cookies / server-side session store) | §3.3 | §9 «Отказоустойчивость» или §13.7 | Не разобрана как триада | **Добавить** сравнение: sticky — теряем при падении ноды; cookies — тяжелее и небезопасно; server session — выносим состояние в Redis/DynamoDB | | **DNS round-robin + TTL dead-node pitfall** | §2.4, §3.2 | §13.1 DNS | TTL упомянут, питфолл round-robin-as-LB — нет | **Добавить** фразу: round-robin DNS дешёвый LB, но TTL приводит к запросам в мёртвый IP; ELB решает | | **API Gateway origin + 4 advantages** | §2.8 | §13.8 API-шлюз | Функции шлюза перечислены | **Дополнить** интервью-формулировку: «почему появился» (монолит→микросервисы) + 4 преимущества | | **Redis single-threaded + I/O multiplexing** | §2.9 | §4 «Кэш» | Redis как класс KV есть; устройства нет | **Добавить** микрофакт: Redis single-threaded, множество соединений — через I/O multiplexing | | **9 LB techniques** (+ Resource Based, Fixed Weighting, Weighted Response Time, URL Hash) | §2.5 | §13.2 «Алгоритмы балансировщика» | RR/WRR/Least Connections/Hash/Random | **Дополнить** URL Hash (кэш-локальность по URL) и Weighted Response Time | | **Cold / Warm / Hot standby** с pros/cons и use cases | §2.7 | §9 «Резервирование» | active-active/passive есть; RTO/RPO размечены karan | **Дополнить** cold/warm/hot как шкалу RTO/RPO; hot standby ≈ horizontal scaling | | **RAS: Reliability / Availability / Serviceability** | §2.7 | §9 | Serviceability не определена | **Добавить** определение serviceability как «простота и скорость ремонта» | *Примечание:* перенос самих фактов в `knowledge-base.md` — отдельная работа вне скоупа TASK-45.14; конспект размечает кандидатов и целевые § для TASK-45.1 или поддержки KB.