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. Структура репо

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.

Примечание: перенос самих фактов в knowledge-base.md — отдельная работа вне скоупа TASK-45.14; конспект размечает кандидатов и целевые § для TASK-45.1 или поддержки KB.