Введение в System Design

Цели урока

• Понять что такое System Design и почему это важно
• Изучить базовые компоненты современных систем
• Освоить концепцию trade-offs
• Узнать framework для решения SD задач на интервью

Предварительные знания

• Базовое понимание HTTP и REST API
• Опыт работы с любой базой данных
• Понимание клиент-серверной архитектуры

Twitter, 2013 год, финал Супербоула. 143 000 твитов в секунду - рекорд, который держался годами. Instagram в том же году продался за 1 миллиард долларов с командой из 13 инженеров и 30 миллионами пользователей. WhatsApp - 450 миллионов пользователей, 55 инженеров, 19 миллиардов. System Design - не про технологии. Про trade-offs: CAP-теорема говорит, что выбрать можно только два из трёх свойств. Нет правильных ответов - есть обоснованные компромиссы.

• **Twitter Fan-out:** при 143k RPS во время Супербоула система генерировала ленты для подписчиков через push - один твит celebrities разлетался по 10+ миллионам аккаунтов за секунды
• **Instagram с 13 инженерами:** агрессивный кешинг в Redis, PostgreSQL для пользовательских данных, CDN для медиа - простая архитектура, доведённая до предела
• **WhatsApp 55 инженеров / 450M пользователей:** Erlang + FreeBSD, минимум зависимостей, упор на reliability - инженерная плотность рекордная для индустрии
• **CAP в продакшне:** DynamoDB (Amazon), Cassandra (Netflix) выбирают AP. Google Spanner добивается почти CA через атомарные часы. Каждый выбор - компромисс с последствиями

Что такое System Design?

**13 инженеров. 30 миллионов пользователей. 1 миллиард долларов.** Instagram в 2012 году продался Facebook с командой размером со стартовый состав баскетбольной команды. WhatsApp в 2014 году - 450 миллионов активных пользователей, 55 инженеров, 19 миллиардов долларов. Не рамки технологий определяют масштаб - определяют архитектурные решения.

**System Design** - это не про код и фреймворки. Это про **компоненты**, их **взаимодействие** и **компромиссы**. Вопрос «как спроектировать Twitter?» - не о языке программирования. О том, как система выдержит 143 000 твитов в секунду во время Супербоула и не упадёт.

System Design - мост между бизнес-требованиями и технической реализацией. Senior-инженер превращает «нам нужен чат» в архитектуру с конкретными компонентами, числами и обоснованными trade-offs.

**CAP-теорема одной строкой:** из трёх свойств - Consistency (согласованность), Availability (доступность), Partition tolerance (устойчивость к разделению) - реальная распределённая система выбирает два. Не три. Нет правильных ответов - есть обоснованные компромиссы. Это и есть суть System Design.

**Аналогия:** архитектор проектирует небоскрёб - не с выбора цвета обоев, а с фундамента, несущих конструкций, лифтов. System Design - то же самое, только для программных систем.

System Design охватывает широкий спектр решений:

• **Выбор базы данных**: SQL vs NoSQL, когда что использовать
• **Масштабирование**: как обрабатывать рост нагрузки
• **Надёжность**: что делать, когда сервер падает
• **Производительность**: как снизить latency
• **Безопасность**: аутентификация, авторизация, шифрование

Зачем изучать System Design?

System Design - не академическое упражнение. Это навык, который разделяет инженеров по ценности и зарплате сильнее, чем что-либо ещё.

**1. Интервью в топовые компании**

System Design - обязательный этап в Google, Meta, Amazon, Apple, Netflix, Яндекс, Тинькофф. На Senior+ это нередко решающий раунд: провалить алгоритмы - можно восстановить, провалить System Design - offer не получишь.

**2. Карьерный рост**

Junior - пишет код по спецификации. Middle - выбирает технологии, проектирует API. Senior - видит bottleneck, предлагает архитектурные изменения. Staff - проектирует эволюцию всей платформы под 10x рост. Каждый переход требует System Design.

**3. Практическая ценность**

Понимание System Design помогает в повседневной работе:

• Понимаешь, почему система падает под нагрузкой
• Знаешь, как читать архитектурные диаграммы
• Можешь участвовать в design review
• Общаешься с командой на одном языке
• Принимаешь обоснованные технические решения

Даже без FAANG-амбиций System Design меняет угол зрения. Перестаёшь видеть только «свой endpoint» - начинаешь видеть систему как живой организм с точками отказа, узкими местами и запасом прочности.

Базовые компоненты систем

Instagram, Twitter, WhatsApp - разные продукты, но под капотом одни и те же строительные блоки. Разница - в том, как их комбинировать и под какие trade-offs настраивать.

Каждый компонент решает одну проблему лучше остальных - и именно это делает архитектуру предсказуемой:

**1. Load Balancer** - точка входа, которая распределяет трафик между серверами. Решает две проблемы разом: масштабирование (один сервер не вытянет 143k RPS) и отказоустойчивость (сервер упал - трафик идёт к живым). Nginx, HAProxy, AWS ALB.

**2. Application Server** - бизнес-логика. Ключевое свойство: **stateless**. Любой сервер обрабатывает любой запрос. Это позволяет добавить 10 серверов за 5 минут - Load Balancer сам начнёт их использовать.

**3. Database** - постоянное хранилище. SQL (PostgreSQL, MySQL) - ACID-транзакции, сложные JOIN, строгая схема. NoSQL (MongoDB, Cassandra) - гибкая схема, горизонтальный шардинг, огромные объёмы записи. Выбор определяется данными, не модой.

**4. Cache** - Redis/Memcached перед базой. Горячие данные - в памяти, latency с 50 мс до 0.5 мс. Twitter держал топ-1000 пользователей в Redis постоянно - их ленты генерировались за микросекунды.

**5. CDN** - Cloudflare, AWS CloudFront. Статика и медиа из ближайшего edge-узла. Пользователь в Токио получает картинку с сервера в Токио, а не из Вирджинии.

**6. Message Queue** - Kafka, RabbitMQ, SQS. Тяжёлая задача (ресайз фото, отправка email, генерация счёта) уходит в очередь - API отвечает клиенту немедленно, воркер обрабатывает асинхронно.

Trade-offs: сердце System Design

**Идеальной архитектуры не существует.** Каждое решение - компромисс. Хороший инженер понимает, чем жертвует, и объясняет почему. Плохой инженер выбирает технологию потому что «все её используют».

На интервью оценивают не «правильный ответ» (его нет), а понимание trade-offs и способность принимать обоснованные решения вслух. «Здесь я выбираю X, потому что...» - это и есть ожидаемый формат.

**Trade-off #1: Consistency vs Availability**

CAP-теорема: при сетевом разделении (Partition) система выбирает одно из двух. Consistency - все ноды видят одинаковые данные в любой момент. Availability - система всегда отвечает, даже если данные могут расходиться. Банковский перевод требует Consistency. Лента Instagram выдержит eventual consistency.

**Trade-off #2: Latency vs Throughput**

Latency - время ответа на один запрос. Throughput - количество запросов в секунду. Google Search: latency p95 < 200 мс, важен каждый запрос отдельно. Обработка логов Kafka: важен суммарный поток - миллионы событий в секунду, задержка на секунды некритична. Оптимизация под одно часто жертвует другим.

**Trade-off #3: SQL vs NoSQL**

Типичная ошибка: выбрать MongoDB «потому что гибкая схема» для системы с банковскими транзакциями. Или PostgreSQL для 100 миллиардов событий в сутки. Технология следует из требований - не наоборот.

Framework решения SD задач

Интервью по System Design длится 45-60 минут. Без структуры - хаос: расплывёшься в деталях на ранней стадии, не дойдёшь до важного, потеряешь интервьюера. Вот framework, который покрывает все ожидания:

**Этап 1: Requirements - задавай вопросы**

«Спроектируй Twitter» - намеренно размытое задание. Что именно? Только постинг или ещё и поиск, рекомендации, монетизация? DAU 100K или 300M? Потоковое видео или только текст? Правильные вопросы показывают опыт - и определяют архитектуру.

**Этап 2: Estimation - back-of-envelope**

Twitter: 300M DAU × 50 твитов в сутки / 86400 = ~170k чтений/сек. Пиковая нагрузка × 3 = 500k RPS. Это уже говорит: нужен aggressive caching, read-replica базы, шардинг. Точность не нужна - нужен правильный порядок величин.

**Этап 3: High-Level Design - рисуй диаграмму**

Старт: Client → Load Balancer → App Server → Database. Затем добавляй компоненты по мере их необходимости - Cache если read-heavy, Queue если есть тяжёлые фоновые задачи, CDN если глобальная аудитория.

Думай вслух. Интервьюер оценивает процесс рассуждения, а не только результат. «Здесь добавлю Redis-кеш, потому что read:write = 100:1, и большинство запросов - чтение одних и тех же горячих профилей» - это правильный формат.

**Этап 4: Deep Dive - покажи экспертизу**

«Расскажите подробнее о X» - стандартный ход интервьюера. Будь готов нырнуть в детали любого компонента: как именно работает шардинг по user_id, какая стратегия вытеснения в кеше, как реализована репликация и что происходит при failover.

Ключевые идеи

• **System Design** - архитектурные решения, которые определяют выдержит ли система 143k RPS или рухнет под нагрузкой первого хабаэффекта
• **CAP-теорема** - фундамент: Consistency, Availability, Partition tolerance - реальная система выбирает два. Банк выбирает CP, соцсеть - AP
• **6 строительных блоков**: Load Balancer, App Server (stateless!), DB, Cache, CDN, Message Queue - все системы собраны из этого набора
• **Trade-offs, не технологии**: MongoDB vs PostgreSQL - следствие требований к данным, не мода. Latency vs Throughput - следствие типа нагрузки
• **Framework 4 этапа**: Requirements (уточни scope) → Estimation (порядок величин) → High-Level Design (диаграмма) → Deep Dive (детали под вопрос)

Что дальше

Следующие уроки: Сбор требований (как задавать правильные вопросы), Оценка нагрузки (back-of-envelope calculations), затем разбор каждого компонента (Load Balancer, Cache, Message Queue) и паттернов (Microservices, API Gateway). Финал - реальные кейсы: проектируем Twitter, YouTube, Uber.

• system-design — связан с

Вопросы для размышления

• Вспомни любой продукт или сервис, которым ты пользуешься каждый день - мессенджер, стриминг, карты. Какие компромиссы (trade-offs) скрыты за его поведением? Почему он иногда показывает устаревшие данные или недоступен - это случайность или архитектурное решение?

Связанные уроки

• sd-02-requirements — Requirements gathering is the first step of the 4-stage framework introduced here
• alg-01-big-o — Back-of-envelope estimation mirrors complexity analysis for systems
• st-01-feedback-loops — CAP theorem and consistency models map directly to feedback loop theory
• prob-01-intro — Probabilistic thinking needed for SLA, error budgets, and latency percentiles
• bt-01-overview — Transport protocols are the connective tissue between system design components
• net-01-intro